I’m working on collaborative audio playlists and was wondering if this design makes sense for atproto.
How it works
-
Two lexicons of importance:
sh.diffuse.output.collaborationsh.diffuse.output.playlistItem
-
sh.diffuse.output.playlistItemhas the following properties (besides the usualid, etc):criteria: which audio track to match with.playlist: the name of the playlist this item belongs to.positionedAfter: the id of the item to position this one after (none = start)
-
The way we associate accounts with a playlist is using a
sh.diffuse.output.collaborationrecord which has these properties:subject(union)subject.kind: “playlist”subject.playlist: matches the name of the playlist itemcollaborators[].id: Points at the handle or DID of an atproto identity (or some other identity were we not to use atproto)collaborators[].hint: Where to go look to resolve the combination of the collaboratoridand the subject (eg.atproto/handle)
-
The cohesive playlist spanning across multiple atproto accounts is built by taking all these playlist items from all the associated accounts, filtering by
playlist(eg. our “Favourites” playlist) -
There’s no central record of who’s managing the playlist, every account decides for themselves who they want in the club. So everyone has their own
sh.diffuse.output.collaborationrecord pointing at the other accounts. This could be a recursive lookup, depending on how you’d want to resolve and extend the graph. -
To sort the playlist items we take the
positionedAftervalue of each one and we keep repositioning until we have the final order. -
Finally we render the cohesive playlist in the UI as a single playlist where can reorder our items.
-
Repositioning other people’s items is not possible with this setup, but might be possible with some extensions to this? Not sure if it’s worth the additional complexity though. My reasoning is that you could always fork the playlist if you really wanted to reorder everything yourself.
Thoughts?