TL;DR: Building graph.one - an open social graph API starting with email/calendar data, expanding to other platforms, with incentives designed to keep it open forever.
The problem:
- Social graphs are walled gardens - I've been burned twice:
- Built on LinkedIn's data → they sued startups
- Built hive.one on Twitter's API (indexed 40M+ accounts) → Elon killed it
- I'm a big fan of Nostr, but don't see a path to bootstrapping a meaningful social graph
- Meanwhile, there's a massive untapped social graph in everyone's email/calendar
The insight: Current social graphs close off because their incentives push them to milk network effects. The key isn't decentralization - it's aligned incentives. This creates an opportunity – if someone created an open social graph, there is potential for a movement to emerge to support it.
Our approach:
- Build as a for profit startup, which is a proven way to create compelling products
- Keep the network open through a novel business model:
- Free API for developers
- Users pay small fee to port their data out
- Platform can't cut off developers without angering paying users
- Start with email/calendar (readily available data), then expand:
- Phase 1: Email/calendar connections
- Phase 2: Import from major social platforms
- Phase 3: Enable connecting any identity/platform
Progress:
- Working prototype at graph.one
- Import your network via Google/Microsoft auth
- SDK coming soon for developers to build on top
Why this matters:
- Developers get reliable API access
- Users can move their social graph between platforms
- Business model supports openness
- No blockchain/crypto/web3 complexity
Would love feedback from SN community, especially:
- Thoughts on business model alignment
- Developer pain points you've hit with social APIs
- Use cases you'd build if this existed
If the openness hinges on this model, it's doesn't seem strong enough for me to believe it yields a forever open social graph.
That said, I think this is a huge insight:
I do agree that the business model in itself is not sufficient to guarantee the graph remains open. This idea is work in progress and I am open to suggestions. My high-level thinking is this:
I'm trying to figure out how to structure the product and the business model in such a way that the most value for shareholders is created when the graph remains open.
You basically need the person that's paying you to stop paying you when it stops being open. You need the value they receive to evaporate when you close the graph off. Once you have the graph, you hold the value and can extract any rent you choose to.
I think you need others to have the graph and ideally many of them. If you can incentivize competitors to also serve the graph, that'd prevent any one company from successfully extorting customers.
What is a social graph? What's the use case?
Social graph is a representation of relationships between entities, in the context of social media it's typically who you know or interacted with on a platform, but it can be broader than that. A social graph can also represent relationships between organizations. For example, you could represent podcasts as a social graph between hosts and guests who appear together on episodes, or the VC/startup ecosystem where each investment is a relationship.
Example use cases:
Ok, thank you, I see now.
But then, the examples you gave are fully covered by Nostr already (either by existing or potential functionality). Calendars and events where already developed. Mail has been discussed, but, shouldn't be that far from current DMs. Can't you build upon that?
I love Nostr, but I currently don't see a viable path to bootstrapping critical mass. The idea here is to leverage an existing, massive social graph to bypass this issue and I can see integrating Nostr at some point.
Oh don't get me wrong, it's not that I'm being a Nostr maximalist.
But that explains your point better, in that you want to harvest what's already in place. Still I don't see why that can't be implemented on Nostr, using it's infrastructure, but connecting the dots based on external information. I think that way you will not only get the best of both worlds but also immense community support, which is another factor to consider if you want to harvest existing potential.
I do think we can implement nostr. It's just that it's not relevant for the initial phase which is about achieving user adoption. I think nostr is great for handling identity long-term, but that would require an already popular platform educating users about nostr rather than the other way around.
Ok! I'm no social-networks expert. I wish you the best!
I love the ambition here—creating a social graph powered by universally used email and calendar data could set a new standard for interoperability. Ensuring privacy and user control will be key to gaining trust, especially if data is sourced directly from personal inboxes and schedules. What are your thoughts on managing privacy within this model, particularly regarding potential risks with sensitive data? Also, could an open protocol for this data sharing strengthen collaboration with existing open-source social initiatives?
Yes, absolutely privacy controls will be critical. We think some users will choose to keep their network private or share with a small group of friends or co-workers, others may choose to make everything open. We envision privacy controls that would enable both extremes, but we have not put those in place yet.