There are 3 somewhat generic properties I’d like to discuss! I don’t have them in Vervis and there’s otherwise no specific need for them that I have in mind, but I do have ideas, and I do want to document them in case they soon do become more clearly useful.
On the Fediverse, as a user you have 2 names basically:
- Your username, that appears in your profile URL
- A not-necessarily-unique arbitrary name you can choose and change any time you like
If I recall correctly, the former is placed under the
preferredUsername property, and is used for WebFinger lookup. The latter is placed under
name and is used just for display in UI. For example, your
preferredUsername may be “alice” and your
name could be “Alice the adventurous explorer”.
Now let’s look at forges and repos. Repos too have 2 names:
- A generally-not-changing string with some strict rules such as having no spaces, which appears in the repo URL and is commonly used in shorthand references to the repo
- An arbitrary free-to-change name string
For example, the former may be “linux-libre” while the latter could be “Linux-Libre: A version of the Linux kernel with all proprietary bits removed”.
I don’t know if the former appears-in-URL name is useful in a federated context, but I do know it’s generally a recognizable name for a repo, much like on Mastodon people can change their name but you’d still recognize them by their
@user@host (and their profile picture and so on).
I’m proposing to have a property for this concept, i.e. a generalization of
preferredUsername for things that aren’t users, such as repos. We could call this property
In a federated context, the only unique reference to a resource is its absolute URI. When displayed in UI, you may wish to use something shorter and recognizable. Sometimes URIs just look random. One thing you can do, to get started, is to separate the URI host and the URI path. And for local resources, you can entirely avoid displaying the host, much like on Mastodon local users are referred as
@user and remote users as
@user@host in activity feed displays. But in a general context that involves not just users but also repos, projects, issues, etc., if you split out the host you’re left with the URI path, which may still look long or even ugly.
A pretty example for a path of a repo URL is
/user/repo, which is used on GitLab and on githu8 and in other places. But there are other options, for example gitweb may use something like
/git/?p=REPO.git;a=summary, and someone may just use random UUIDs in the URI.
It could be nice, and maybe useful too, to have some way to refer to the logical position of the object on the instance, even if the object’s
@id URI is ugly and isn’t useful or friendly to human eyes. We don’t have to require this logical position reference to be unique among all the objects hosted by the instance; maybe it’s enough for it to be unique among objects of its type, and the UI can display an indication of the type, making it recognizable reference to the object much like
For example, at pagure.io, some repos are at the “top level” namespace, and their URI looks like
https://pagure.io/REPO, and some are on a secondary namespace, e.g.
https://pagure.io/GROUP/REPO. For the former case, you could say the namespace is
REPO, and for the latter it’s
GROUP/REPO. Even if the URIs weren’t that pretty, and looked random, having access to this logical namespace info could be useful. For example in the gitweb example,
/git/?p=REPO.git;a=summary, the namespace would be
Perhaps we could have a property
namespace for this.
So far in ForgeFed we have 2 kinds of objects:
- Objects that are generally agreed to be actors, and you can interact with them by POSTing to their inbox
- Objects that aren’t necessarily actors, but you still may wish/need to interact with them, and that happens by POSTing to the inbox of the actor who “owns” the object
In the basic microblogging model e.g. in Mastodon, the object situation is in a way simple and everything revolves around users. But in the context of forges there are more types of objects and relationships, and it would be nice, and possibly very useful, to have a general way to determine how to interact with a given object, even if it doesn’t have its own
inbox, and even if you don’t recognize its
So I came up with a property named
managedBy. If an object isn’t an actor, but is interacted with via some parent object, then
managedBy is a way to point from the object to the parent that is an actor and has an inbox.
For example, suppose there’s an issue dependency object, that says “issue #2 depends on issue #1” and as a project team member, you decided to remove this dependency. You probably want to send a Delete activity, or maybe a Remove, but to whom do you send it? If issue dependencies aren’t actors, it would be nice to know who the responsible actor is. If you know ForgeFed terms, you can look at the issues #1 and #2, maybe discover they belong to the same repo, and check if that repo is an actor. Or some other logic. But if there’s no clear algorithm, or if your software doesn’t understand all the ForgeFed terms and tiny details, you can look at the
managedBy property of the issue dependency object, GET the specified URI, which should be an actor with an
inbox, and send your activity there. It allows for flexibility, because instead of having strict structures and algorithms (which isn’t necessarily easy because each web app has its own way to organize things), you can have this more generic property you can look at.
QUESTION 1: What are your thoughts about these properties?
QUESTION 2: Should we add them to the spec, and remove later if not really useful, or wait until there are signs of real need and use? It’s also an issue of spec clarity: These properties give real world access to otherwise abstract concepts, so I think it adds some value to mention them alongside the descriptions of the concepts.