We covered a lot of ground in Montreal on a number of topics. Read the leaflet for the high level notes.
To go into some more detail, we talked about collaborative, shared data and permissions, and personal private data.
@iame.li is intending to build out a PDS implementation for Streamplace (“Best PDS”) because of high resource needs of streaming video storage. And, has a need for some personal-private data.
For a lot of things, we talked about URI segments in at URI paths. Inserting personal-private in a path will be invalid for PDS implementations that don’t support it.
We talked through what it means to have PDS hosts and thus accounts with varying capabilities in the network.
As app builders, do we have to do capability discovery on the PDS that an account is on?
@awarm.space from Leaflet in particular pointed out that a lot of those flows would be unacceptable for a product experience – Leaflet already implements various private / permissioned data on their app backend.
The one thing we came up with is perhaps having a private data service endpoint in the DID doc for an account.
So, if Private App runs a Private Data PDS and people sign up for an account on their PDS, then both the public PDS and private PDS service endpoint would be set to that server pds.private.app.
If someone logs into Private App hosted on a Bluesky PDS, their public PDS endpoint would be morel.bsky.network. Private App could prompt to set private PDS endpoint to pds.private.app.
Pro: any app that wants to implement private personal data can run a private PDS and support it for any account.
Con: a user has data on two PDS hosts.
This is an example of how to implement things. What was most useful was talking it through with real examples. Leaflet already has app specific private data and collaboration, and Semble is planning to do shared collaborative data, and would also like a private shared data approach. @iame.li is moving forward with a custom PDS implementation, likely the first of many.
