Unique user reference, changing pods, backup

Development
1

Hi there,

Just a bunch of raw ideas. I really wish one day diaspora can replace facebook. Open and distributed social network means freedom. Cheers!

Usernames should be unique within the whole public diaspora network. This could be achieved by setting up directory servers handling the list of all users saying which pods are hosting them + one e-mail address for user verification purposes. Directory servers’ only purpose would be to store the users/pods/e-mails database (not passwords, since logon is pod distributed).

It could make the network more resilient in case of a pod failure, as the user would just have to choose another pod while keeping his/her username. It also makes it simpler to other users because reference to a user would now remain unchanged whatever the hosting pod (directory servers translating unique username to actual user@pod address).

It would also be easier for any user to choose a different pod spontaneously for whatever reason. Signing up to a different pod with existing username would have to go through e-mail verification and, if passed, would trigger deletion of user profile hosted by former pod. We can even imagine a direct pod-to-pod migration tool.

User should regularly backup his/her profile on a computer or cloud service. It should be strongly encouraged, using a backup scheduling tool perhaps. Backups would be restored by user in case of pod failure or for moving to another pod.

2

A couple of questions,

  • This sounds like you’re just moving the dependency from one entity to another. Instead of users depending on the pods being up, they’d depend on the “directory servers” being up. And actually, they’d depend on both their pod and the directory server being up, since the pod going down would still result in loss of data.
  • How would you make sure those “directory servers” actually know about every possible user, without introducing a gigantic scaling-bottleneck, and without distributing PII to random servers?
  • Ignoring the fact that eMail validation is a bad security measure, as social engineering your way into an email account is easy - how would you prevent a malicious “directory server” from allowing all account verification requests without actually verifying anything?

In theory, you could mitigate some of those issues by requiring every user to host their own “identity server”, for example something like “you can host your identity on your own domain”, but if we’d require that, there would be no benefit over users hosting their own pod in the first place, and it would also not help people without the ability or willingness to host their own stuff.

3

Thanks for replying.

Just as a reminder we are talking about public diaspora network here. Private communities would still rely on their own pods only, without need for a directory.

Of course this system makes directory servers critical but allows temporary failure or unavailability.

Existing users wouldn’t depend on directory servers being up, they could still log in through their hosting pods.

Only new and migrating users would require directory availability. Implying sign up process is only achievable when directory is available (to guarantee unique username).

Sign up validation should occur through the pod, not the directory servers. Other means of validation could be implemented (phone?..)

Maybe pods could have a cache holding only the external usernames (with matching pods) they need (like DNS?) and query directory on a need-to-know basis instead of systematically.

I’d like to bring up 3 signing up scenarios

¤ New user

[user]: I’d like to sign up on this pod with username bob12
Pod checks directory for existing bob12
[pod]: Username is available, please choose a password and give e-mail address
User gives info
Pod sends activation code via e-mail
Activation succeeds; pod adds user bob12 to the global directory, with matching pod address and e-mail
User can now login through his home pod

¤ Existing username

[user]: I’d like to sign up on this pod with username bob12
Pod checks directory for existing bob12
[pod]: Username already exists, sorry, choose something else

¤ Existing user changing pods

[user]: Hey, new pod, I’m bob12. My old pod blew off, I’d like to settle in.
New pod checks directory for bob12, fetches back the e-mail address and sends activation code
Activation succeeds; pod updates bob12’s info into the directory
User can now login through his new home pod
[new pod]: welcome back to diaspora, any backup to import?

I don’t know about how to legitimize/secure directory servers or how to distribute queries and info or what kind of structure would be fit for this directory need. I’m not going to pretend, this is WAY beyond my knowledge. Hence I might sound totally crazy because none of this might actually be feasible (is it?).

However, I am convinced that unique user reference is needed if we want to take diaspora to a bigger scale. Otherwise it’s going to remain an isolated geek fad. I am also convinced that distribution remains an imperative, to face both inherent technical vulnerability and power accumulation.

Too much power in a same spot always ends up the same way. Look what happened with FB. It started with a funny college project, now Zuckini is like a spoiled child longing to rule the world.

4

I would second this, the directory need not be large and the complexity would be moved to a database process.

This is an off the cuff design, and I’m certain there are gaps… but I think that the concept here is sound.

The directory would only store the minimum amount of information. A globally unique id, credentials, canonical source. The store would be a distributed K-V database with a sharded distribution model. There are many choices that already exist and are mature.

Each Pods would have a ‘shard’ that is specific to the users signed up from that pod.
This means that users of that pod have no latency to sign up and their account is always at their pod. This would work equally well if you do not have a connection to other pods (either temporarily or by design).

For private/local pods, you simply don’t share your database. Technically it would still be a ‘shard’ but it would never leave your pod, etc.

If you use the public directory, then each member replicates shards based on their available resources and a distributed voting mechanism. The ‘shard’ of that database would be replicated via the distributed network (based on available disk space). Pods with sufficient disk space could replicate the entire directory. The originating pod is still canonical, but if it is down then a replica can be used.

Using OAuth for authN already provides fine grained control without creating something new. Each of the pods act as an OAuth provider. The access to specific pods would be controlled via OAuth access tokens. The ‘public’ pods would simply auto-approve these, the rest would require admin approval. As a side effect, this could offer a ‘login with Diaspora’ capability. This would also provide parity with well known social media providers.

A few gaps:

  • The OAuth access token would probably need to be still be generated, this needs to be investigated.
    • If so, it would have no access until approved.
  • A mechanism to determine the number of replicas that exist would need to be established (either built into the database or some extension).
  • I do not know if the seed/user id is current guaranteed to be globally unique, if so that may require a new mechanism.

I am a newbie to Diaspora, yet even with my technical knowledge… I had a heck of a time understanding how to sign up and what it meant. Simplifying this process would greatly enhance adoption while also adding new functionality.