Given streams are interoperable across applications, it is still useful to “group” them by applications where the data is generated, how should we do this without relying on external index?
A convention or CIP regarding how this info should be recorded would help improve the interoperability of schema
{ “tags”: [ “credential” ], “family”: “orbis”, “unique”: “ocYriGMGTivnI4pQ”, “controllers”: [ “did:key:z6MkfGLpuLq7vVXU93xRH1mLghA5FmutCGmUWKZ1VuwT3QJu” ] }
Could we rely on tags and family?
One of the main goals of Ceramic is to not silo information with specific apps. Therefore using tags or family for this purpose is not really the best approach imo.
Most apps today use DID Session, which create a session key by using SIWE. If you parse the log and retrieve the CACAO (object-capability) for the session used you will be able to find the origin of the app that authored the given commit!
1 Like
Understand the anti-silo intention. But from a user experience perspective, it would be great if he or she is able to find out about what action he did within an application context without all mixing up
Or from an indexer perspective, how should I index the update streams with the relevant application context?
As Joel mentioned, the data itself on Ceramic is designed to be cross-app so we don’t want app-specific data in the actual stream content itself. This is not how ‘family’ or ‘tags’ were designed to be used. But as Joel said, if you use did-session, then the user has to sign a SIWE (Sign In With Ethereum) message to authorize the app’s temporary session key to write data on their behalf. So if you inspect the capability object (CACAO) in the stream commits, you can see what application was used to publish the data, based on the origin that was used for the SIWE message that the user signed.
1 Like
Thanks for the prompt feedback @jthor @spencer This really helps. We will try the CACAO approach, it seems sufficient for our use case.
Just to clarify, the use case is building a application independent data explorer, like etherscan, so that even if the app is down, user could still find out about his data foot print across applications. So this is entirely aligned with the cross-app data thesis rather than against.
1 Like
just to confirm, so tags and family are deprecated and should not be used at all?
Hey @0xEE3CA4dd4CeB341691 thanks for the link. How are you retrieving all the streams for a given DID?
I don’t think they are supported out of the box for old tiledocument streams without using a Indxer like https://s3.xyz . For new streams via ComposeDB, I think you could query like this Queries | ComposeDB on Ceramic
tags and family are features only of TileDocument streams, they don’t exist on the newer streamtypes used by ComposeDB. While we still technically support TileDocument, we also aren’t doing any active development on it anymore and are strongly encouraging all new devs to build on top of ComposeDB
Yeah, with ComposeDB you can easily see all the streams from a given DID in a given data model. There’s still no easy way to see all streams for a DID across all data models currently.
1 Like