Building an open social graph - backed by email/calendar data \ stacker news ~tech

pull down to refresh

Building an open social graph - backed by email/calendar data

3534 sats \ 12 comments \ @maciek 3 Nov tech

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

view all related items

420 sats \ 2 replies \ @k00b 3 Nov

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

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.

I'm not sure people will pay enough to port their social graph out to sustain a business
Even if (1) is wrong I can't be sure that once this service grows, you won't want to make quarterly earnings with a surprise API pricing change (angering users that are locked in happens all the time)
- if you can put a paywall for one type of person, you can put it up for anyone at your business's discretion

That said, I think this is a huge insight:

Meanwhile, there's a massive untapped social graph in everyone's email/calendar

162 sats \ 1 reply \ @maciek OP 3 Nov

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:

The more the platform depends on the revenue from its users, the more it is incentivized to act in their interest
The network effects can be established on the platform level, or integrations. I.e. the ecosystem of connected apps and platforms can, in itself, create a network effect

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.

121 sats \ 0 replies \ @k00b 3 Nov

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.

0 sats \ 1 reply \ @unkempt 4 Nov

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?

0 sats \ 0 replies \ @maciek OP 4 Nov

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.

0 sats \ 6 replies \ @didiplaywell 3 Nov

What is a social graph? What's the use case?

189 sats \ 5 replies \ @maciek OP 3 Nov

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:

Bootstrapping network on a new social media platform – you can automatically follow/connect people you already know
Podcasting app – you can automatically find podcast episodes with people you know/follow on other platforms
Email client – you can see what friends you have in common with the sender
CRM – you can see who can introduce you to a lead

126 sats \ 4 replies \ @didiplaywell 3 Nov

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?

104 sats \ 3 replies \ @maciek OP 3 Nov

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.

21 sats \ 2 replies \ @didiplaywell 3 Nov

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.

104 sats \ 1 reply \ @maciek OP 3 Nov

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.

0 sats \ 0 replies \ @didiplaywell 3 Nov

Ok! I'm no social-networks expert. I wish you the best!