User Directories in Diaspora
Sean Tilley
Public
Seen by 24
One thing that I really like about RedMatrix is the concept of the directory. In a nutshell, it provides an opt-in federated directory for members on hubs to make use of. This can be useful for several things:
Contact discovery - many people moving to the federated web have difficulty finding their friends, who could be on any pod anywhere. A directory could make finding friends much easier, regardless of where they are.
Censorship resistance - rather than being a centralized directory, members that opt in are mirrored between directory server sites, and any of these mirrors can provide directory services to smaller sites or those that don’t wish to take on the directory role themselves. A tally is maintained for how many times they've been blocked by people in the network, but it's up to the podmin to decide whether to block it in their directory or not.
Currently, Diaspora makes use of content discovery through profile hashtags, but it's not federated across all instances in the same way.
Just some food for thought.
Sean Tilley Wed 19 Nov 2014 2:32AM
Thanks for clearing that up, Mike.
Rich Wed 19 Nov 2014 6:27AM
Does it scale well? To say 1,000,000+ users?
Jason Robinson Wed 19 Nov 2014 6:43AM
Sounds awesome :) But personally, I find that the diaspora* core should do one thing well and only that - act as a social media server.
IMHO directories for d* could be small server apps themselves that could be hosted by anyone and in pod settings podmins could have a config setting for the "main" or first directory to use. Directories could learn from each other etc, but otherwise, they would just be directories and offer directory services. Pod users could query them, add to them, etc. Directories would also offer a search endpoint that pods could hook up to (chosen in settings).
I know this isn't a purely decentralized model, but as said before, the diaspora core server is already too heavy. Personally I wouldn't add anything more to it. It's not just performance, but it's also code burden. IMHO a component architecture is better than do-it-all, for diaspora. Redmatrix I understand, since it's more of a do-it-all solution for federated social spaces. But diaspora* is more like a traditional social media server app.
But the problem Sean describes is a huge one for diaspora. Discovery is really limited and should definitely be improved (including searching by metadata, like other socnet usernames, for example). But should that part be a part of the core? IMHO no.
Elm Wed 19 Nov 2014 7:00AM
Hello, this is interesting and I think that users should have the choice of being in that directory or not (and not only at subscription). Searching people is a way to contact forgotten friends or people you met but since many are using a pseudo for their subscribtion account name and for their profile name, it limits the interest of such an option.
As for me, I have an FB account that I keep just for that : people can find me there and follow the link to D* if they really want to be in contact and discuss with me.
Mike Macgirvin · Wed 19 Nov 2014 2:27AM
Just for accuracy, the directory is not federated across all instances. It is mirrored between directory server sites, and any of these mirrors can provide directory services to smaller sites or those that don't wish to take on the directory role themselves. There are currently 9 mirrored directory servers out of about 300 sites. Additionally there are 7 "standalone" directory servers which are essentially private directory domains that are running disconnected from the overall matrix. (Clusters of sites can also participate in directory "realms" which can be hierarchical or clustered, much like [ugh] Active Directory).
A directory administrator can censor an entry, but it is still available to anybody. One just needs to enable/disable "safe search", which is safe by default. In rare cases a site can blacklist or block an entire server. We put this mechanism in place during the IS fiasco and it is currently unused but is available if we require it.