Actor Mentions

ActivityPub Server to Server
,
1

(This topic was originally posted to Decentralised Group and moved to its own separate discussion topic)

Hello,

I’m new to all things activity pub so please forgive me for my possibly novice opinions.

While I feel that this FEP is a step in the right direction, we could peruse a more flexible approach for exclusive namespaces for actors.

Rather than adding only two new special characters, we can allow for a list of characters that can be legally used in machine generated[0] actor identifiers. This allows for a more richer description of actors.

For instance, when describing the function of buildings in a city, hospital identifiers can have a ! for prefix, $ for restaurants and ^ for houses. By treating identifiers opaquely, actors won’t have to commit to any interfaces beyond other than the ones defined in the base actor class but it will enable the host instance to extend actor base class without having to deal with namespace collisions.

Additionally, opaque identifiers will enable implementers express richer relationship rules using just identifers. An organization with PR and development departments and each department having a separate admin group can describe them as !<org name>$<department name>^<group name>(with !, $ and ^ being special characters for organization, department and group respectively). We could express this relationship in the actor document but a hierarchical identifier will also assist the user to quickly determine the entity an identifier represents. An alternate approach with context-aware identifiers would result in namespace exhaustion and unwieldy identifiers like <org>-<department>-<group> which will be assigned on first-come-first-serve basis.

[0]: user provided being the one the user enters during registration. I chose @realaravinth for my username on this platform and so I’ve been assigned the same but if I were to create a group called “friends”, the program can generate an identifier for that group similar to <special character>friends. The difference being, the user didn’t choose <special character>.

1 Like
2

I like the concept you’re introducing (although it is really difficult to come up with safe prefixes that won’t result in too many false mention hits). But, I don’t think any ActivityPub implementation depends on the prefix.
GNU social has always used ‘@’ for persons, ‘!’ for groups, and ‘@#’ for collections, but it is not something we depend on agreement for federation in GS.
For example, if you’re using GNU social via SMS on a T9-keyboard (old smartphones), it will accept T nickname mentions and federate correctly (and other softwares will receive the mention as a T, even if they don’t have such functionality).

3

Apologies. It seems the problems that I’m trying to solve is specific to Mastodon.

I’m working on a software forge federation called ForgeFlux. Repositories are modeled as group actors in the format !{user}!{repository name} and Mastodon didn’t even query webfinger for repository but both GNU social and Pleroma successfully queried webfinger and even recognized the actor.

Perhaps what I described is a separate FEP. Thanks for your time :slight_smile:

4

No problems! I’m always happy to learn that GNU social is behaving correctly with new and untested scenarios :slight_smile:

1 Like