Question about the permissioned spaces spec: will there be anything defined at the protocol level regarding discoverability of spaces that you got added to? It looks like listSpaces only lists the spaces you have written to (have a spaceRepo for), so that would be post-discoverability. Seems like this would need some sort of notifyMembership procedure and would fall on the PDS to keep track of spaces a user has been added to?
I vaguely remember discussing this at ATmosphereConf and lost what happened to this thread, but don’t think I saw it in the official proposal spec.
BTW, this came out of our work pre-implementing the spaces proposal, more details here: Habitat's road to release: 01 simplespaces - building [at] habitat
4 Likes
I yoinked your question to a new top level post @offline.arushibandi.com – please DO start new threads for questions (same goes for anyone else).
I’m guessing @dholms.xyz is just recovering from his European adventures.
1 Like
Thanks @bmann.ca. Yeah I’ve had my head deep in implementation stuff since getting back from Europe and done a bad job keeping up on forum discussion!
If I’m being honest, I’m not quite sure on this. I’d rather get away with not needing a notification. Right now, there are basically no vectors on the PDS for an “unsolicited push”. Those generally tend to accumulate spam and you have to start building defenses for them, which is difficult to do generically. This would open up a vector for that. Space spam where someone keeps adding you to a bunch of spaces and clogs up your PDS with nonsense spaces that you have access to.
It’s also a bit tricky because “membership” is fuzzy and not really a protocol concept. It could be temporary, driven off of some application semantic, or require a particular client.
In many cases, I think this can be solved at the application layer. For instance, if you use the same application as the creator of the space, then that application can help give the notification. In my current draft for atmospheric communities, I’m going to propose a “invites” space hosted by each user that communities can write into to deliver an invite (I’m more comfortable with this because it’s in userland & thus can be interpreted by applications as opposed to in the protocol).
Do you have a particular usecase in mind that could motivate this?
2 Likes
Yeah we’re thinking about it mainly for interoperability. For example, if we wanted to interop between slack/discord like apps where each channel is a space, you’d want each app to be able to discover the channels a user has been added to even if they haven’t sent a message in it yet. Or for a collaborative doc editor where each doc is a space, you’d want to know which docs you have access to even if you’re using a different app from the sharer.
Maybe a way to do it without spamming each PDS is to have endpoints on a space host to list spaces a user has permission to (gated by service auth/delegation token). Then the problem becomes how do you discover space hosts. This is may be easier to solve for: an application can look at like follower graph or the user can write a record saying “I’m interested in this space host’s spaces that I have access to”. This is probably sufficient for our organization use case where a user can just ask their org but might be limiting for the broader ecosystem.
Right now, there are basically no vectors on the PDS for an “unsolicited push”.
Based on the simplespace spec, if you have a public simplespace won’t that PDS get spammed with unsolicited notifyWrites? That would be another way to implement interoperable space discovery: you have a dedicated space (like at://<user>/space/space.discovery.type/self) where other users can publish records that point to spaces that you have access to. But yeah that’s open for spam.
1 Like