User:DeadSuperHero/Proposal:User Directories in Diaspora

From diaspora* project wiki

This proposal is a work-in-progress. The purpose is to revisit some of the core ideas in how user discovery is currently done within Diaspora as well as the wider free web.

Current Implementation

At the moment, Diaspora has three pieces of the puzzle regarding user discovery. These three methods have historically played a part in how Diaspora users end up connecting on the network.

  1. Tagged Searches - Searching for tagged posts brings up profiles of anyone that has those tags associated with their profiles.
  2. Community Spotlight - Pods can feature a handful of its members on a special page for other people to discover and follow.
  3. Search Lookup - Members on a pod can be searched for by their username or handle.


  1. Tagged Searches - User profiles can only have 5 tags, and not all search results for tags are necessarily shared between pods.
  2. Community Spotlight - Although it works well as a feature, community spotlight primarily just features a few profiles that are given a community spotlight user role. This mostly exists as a minimal local directory for pods; results are neither shared nor federated between pods.
  3. Search Lookup - Although a webfinger request usually works well enough for adding a contact, newcomers may not be sure of how to do this, and might find it difficult to find their friends who might be on any given pod at any given time.

RedMatrix-inspired Implementation

A directory for a RedMatrix hub.

For Red users, the directory 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.

Within the Red ecosystem, 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 Active Directory).

Implementation Specs

Current details found from Red Wiki; this section is subject to updates.

  1. Directory Structure - Perhaps the easiest way to describe the Red Directory at a high level is to provide a comparison to the current Friendica Global Directory. The Friendica Global Directory consists of two levels - a site directory, and a single Global Directory. Permissions are granted by members to appear in either or both. The Global Directory is a single instance running at, and communicates by xml messages and scraping profiles to obtain information. The Red Directory does not have two levels. It is a single, replicated global directory which can be mirrored anywhere.
  2. Censorship - The most problematic aspect of a global directory is the ability to flag indecent/adult profile information. The Red Directory will attempt some novel solutions in this regard by providing a web of trust. Anybody may censor a profile entry using facilities with the Red Directory search interface. This will unconditionally block the entry from their view on a personal level and without question. This information will also be sent to the nearest mirror. An accumulation of block messages will lead to the entry being blocked at the directory level. The number required cannot be a fixed number, as this would make the system open to manipulation. Additionally, a mirror may indicate a trust level with other directories, and only block an entry if there is consensus amongst its peer group. Finally, a "block" does not remove or even block an entry from being displayed in the directory. It adds an "offensive" weighting to the entry. Individuals can set a weighting on a personal level of entries that they are comfortable viewing. The more peers which flag an entry, the higher the weighting.
  3. Zot Directory Update Messages - There are still some communication details to be worked out, but the best model at the moment is to provide a single zot_uid to be used for directory information. The zot_uid is the exact string "Directory". Being a zot_uid means it can be initiated from any location. Since the directory contains only public information, the messages will not use encryption and not require key verification.


  1. Users would be easier to find across pods, regardless of what pod they're on. This could help connect people on "island" pods connect with people on the wider free network.
  2. Profiles could be filtered through based on whether they were local to a pod, or part of the wider net.

Discourse Discussion

The Discourse discussion about this can be found here: