Graph interoperability for a subset of the spec

DSNP
1

Hi all,

Thank you for the great work on this project! I have just started digging into the white paper and documentation, and have been learning a lot. The contract delegation mechanism is well designed, the ability to incorporate Activity Streams 2.0 is nice, and I also look forward to seeing how the result of chain selection be.

We at Matters Lab are solving a very similar problem. We have nearly 80k content creators, mostly Chinese speakers, to whom decentralization and censorship-resilience are high priorities. We have been storing content with IPFS in the production environment for 3 years and will move our social and content graph to an Etheruem layer 2 next year, likely Polygon.

Our goal has been to find the simplest way to build a shared social & content graph that actually works while keeping the cost low. This is similar to DSNP, but with a smaller scope: instead of a full-fledged protocol, we are aiming at a data schema that fulfills our current needs and can be iterated on later. Therefore we are only defining a set of on-chain events that signifies updates on the social & content graph, which can be aggregated (and upgraded) by indexers such as The Graph, servers, or frontend clients.

The event spec we are developing looks very similar to the Announcement Types defined in DSNP. So my question is if we only use this subset of DSNP spec, are there any ways for our graph to be interoperable with the graph that DSNP is building?

Or frame it another way: in DSNP’s design, what is the minimal requirement for graph interoperability?

Thank you in advance and congrats again for the great work!

2

Hi @GuoLiu!

Sorry for the slow reply, we’ve been in and out with holidays.

It sounds like our goals and approaches are very similar.

That’s a good question. We’ve had thought experiments about how to interoperate or bridge to other identity and/or content systems. That’s part of why we ended up with the dsnp://[id] identifier setup.

I think there also could be changes to the graph spec once we have selected a chain that could make interoperability easier. I’d love to talk more with you and your team about your needs and use cases. Also about how you are approaching thinking about Layer 2 Ethereum and costs.

Have you published documentation yet about how your are approaching the event spec?

Thanks for reaching out and looking forward to seeing what we might (at a minimum) learn from each other!

3

Hi @wil ,

Thank you for your reply! Yes, we have very similar goals and approaches. Would love to connect with you and your team to see how we can help each other and work together! I will message you my contact.

Have you published documentation yet about how your are approaching the event spec?
The event spec has not been formalized and is only discussed internally at the moment, but we do have our data schema defined in GraphQL, see the playground here. The events will be used to update a subset of this schema, so roughly correspond to the mutations.

Looking forward to learning about what you guys are thinking and building!