FEP-c390: Identity Proofs

[angus]

Great questions! Let me see if I can give some context and then go on to engage with them.

@bumblefudge

Could I ask you to say a little more about the “staged accounts” concept, and how @how1 “got there”? In this example, how created an account on the taler discourse server with, e.g., username and password, and only later taler started federating, so Taler created “staged” accounts for all existing users automatically?

Identity objects

These are the identity objects in play here:

TALER

• How’s TALER User account (“T User”). The account he signs in with on TALER.
• How’s TALER ActivityPub Actor (“T Actor”). This is created from T User when it is first needed (i.e. a post made by T User needs federating)

SocialHub

• How’s SocialHub User account (“S User”). The account he signs in with on SocialHub.
• The “staged” User for T Actor, when T Actor’s activities are processed on SocialHub.

SocialHub also stores a local copy of T Actor, but that is a reference object (i.e. with the AP id and attributes of T Actor).

Staged users in Discourse

Discourse’s concept of “staged” users was created relatively early on in its life to process incoming content from email addresses not already present in the system. For some background see here

Invite someone to join and give them a staged user account

One way to think about this is that Discourse was designed to migrate mailing lists (e.g. GNU mailman) to forums (it even has a “mailing list mode” which lets a user basically treat the forum like a mailing list). In that context, the idea that you will need to create a user account object for someone who has never actually registered makes some sense. Within the context of email, the UX of staged users works relatively well because a user simply has to register with the same email as the staged user to “claim” the account. Email addresses do make things easier. One might say that email is still the “killer app” of both distributed identity and distributed discussion (only half joking)

@erlend_sh could probably give further context on UX issues with staged users in Discourse (sorry for dobbing you in Erland)

ActivityPub staged users and UX

The ActivityPub plugin is the first time that concept has been extended beyond the context of email, and it does indeed pose some potential UX issues. I think can address some of your concerns however

@bumblefudge

staged accounts might be less likely to see or respond to comments

Keep in mind that if someone is replying to a post associated with a user staged by the ActivityPub plugin (i.e. associated with a remote Actor), that reply will be federated as well. For example, you can see my user account on SocialHub engage with a discussion with @how’s account on TALER here

Can you hear me Fediverse?

Yeah, perhaps something that could be added. Note that this would probably have to be targeted at Announces (i’ll use the standard terms instead of Mastodon’s) by Persons, and still accept Announces from Groups, as that is how some Forum actors (e.g. Lemmy and Discourse) share Objects with Followers.

A version of this UX concern occurs on any fediverse platform. You don’t need to necessarily worry whether the Actor has an account on your instance to engage in discussion with them. Now, this flow would be undermined if either Discourse, e.g. TALER or SocialHub, remove the ActivityPub plugin, however that is also effectively the same as a fediverse server going offline, meaning the Actors on that server are no longer able to engage in discussion.

@bumblefudge

and users might appreciate flagging them clearly in much the way low-trust/low-activity users are already flagged in discourse

I agree. There are perhaps two aspects of this, the visual cues on the user itself, and the UX of the content (i.e. the post). For the visual cues on the user, as you can see in my screenshot above Discourse already identifies “staged” users. You’re making me think that we should perhaps also add a link to the Actor’s remote profile (e.g. a link to T User’s profile on S User). In that vein, there is already a clickable ActivityPub status symbol on posts (clicking it shows a modal with details about where the content came from, including a link to the original post on the remote instance), but its currently only visible to staff, and I do think it makes sense to surface it to standard users, see

The Social Web Community Group in the W3

This is what happened: Thanks also for the feedback! There is an ActivityPub status, but it’s currently only visible to staff. [Screenshot at Mar 01 16-33-31] [Screenshot 2024-03-01 at 16.33.08] This feedback is useful for my internal case that it should be visible to all users

@bumblefudge

Also, impersonation of various kinds (including accidental impersonation, people using their favorite KPop singer as their avatar, etc etc) lead to all kinds of confusion when staged actors mingle with the more deliberate ones.

True, although the UX delta between this specific case and the standard ActivityPub case is not overly large, i.e. I think this is a problem inherent to the fediverse. I think perhaps the UX concern more specific to the forum context, and Discourse itself, will be that users are not necessarily “expecting” this issue in this context, albeit they may have already experienced a version of it within the email context.