Remote Users

Software
1

From what a quick research brought up, it seems like Mastodon distinguishes the authentication entity (user) and the identity entity, while Pleroma combines both in a single entity.
(In the Mastodon schema the users table has an account_id column whereas in Pleroma the user entity has an local property)
(Authentication here in context of instance-local authentication using, for example, username and password.)

For ForgeFed and implementation of it in existing forges there were some similar discussions on what way is better suited for which situation. And, IIRC there a third approach came up, which stores remote users in an additional entity.

So, my question is, what are your arguments for using one or another?

I’ll share my view in a reply so it’s a little bit separated from the question itself. :slight_smile:

2

I am in favor of the separated identity approach (i.e. separated authentication/login information and identity entity).

My two main points why I favor this are:

  • this makes it easier to allow multiple users control a single identity (for example a project’s new account)
  • it separates concerns: Login authentication does not need to care about (AP) identity and the other way around

My points opposing the single-entity approach are:

  • table size: if you put local and remote users into a single table, the table for login unnecessarily grows (which might slow down login)
  • implementation of the “multiple users control a (shared) identity” is more complex

A point in favor of the single-entity approach:

  • it is very simple.

Regarding putting remote user into an own entity table, I oppose it

  • it adds complexity: anywhere you have a user you need to decide whether it’s local or not.
3

which way works better is dependent on the software design of the implementation, I don’t think the spec should care.

4

I did not suggest this is spec-relevant, is your intention to say that #activitypub category is not the right place to discuss this? :slight_smile:

5

it just seems like a bit of a pointless discussion to me. the details are always going to depend more on the software involved then anything else.

1 Like
6

I concur.

FWIW, Chapeau makes them separate only because Django already has a user management system which it didn’t make sense not to reuse. The rather ludicrous alternative then would have been to give potentially everyone in the fediverse a user account with a “no-login” flag.

1 Like
7

That’s the kind of information I was and still am interested in. :slight_smile:

Like, finding which way was chosen by reading the source code is not hard; the why (which I am interested in) is much harder to find that way.

1 Like
8

I looked at the Mastodon database schema and saw that there are separate tables for users and for accounts… Which is kinda ingenious, so I did the same thing. The idea is that account is something that you use to authenticate, keep preferences in, etc. User is something that can post posts, like posts and so on. So, every account has an associated user, but not every user has an associated account because only local users are supposed to be able to log in to your instance.

That said, my users table has many NULL fields for local users - for example I don’t store any URLs for them as I’m obviously able to generate these dynamically.

2 Likes