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:
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:
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 slug.
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 @user is.
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 REPO.
Perhaps we could have a property namespace for this.
So far in ForgeFed we have 2 kinds of objects:
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 @type.
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 terns, 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?
Feneas forum thread