In Wikidata, we can annotate entities having a mastodon account with the predicate Mastodon address. However, it does not include the addresses in the other platforms. The current predicate that can be used for this is website account on. However, this predicate is less informative because it does not imply that the account is part of the Fediverse. Situations like this are downplaying the Fediverse. Hence, we should propose a predicate for the Fediverse account. Such a predicate should be proposed in the Wikidata Property proposal.
We need supporters
We need some supporters, but no or very few opponents. Who will support the creation of the predicate?
We need a name
What should be the name for this property? Some possible names are the following:
“Fediverse address” in English, and “dirección en el Fediverso” in Spanish.
“WebFinger address” in English.
“ActivityPub address” in English.
One of these names should be the preferred one, and the others the aliases.
We need a datatype for this property
What should be the datatype for this property? Some options:
A string with the form user@server.domain (like with the Mastodon address property).
A URL (but URLs are too flexible, and this would be incompatible with was already done with Mastodon).
We need examples
We also need to define some examples with existing Wikidata entities:
In a future, this property should replace the “Mastodon address” property, instead of saying that LibreOffice has the Mastodon address libreoffice@fosstodon.org, we should say that it is the “Fediverse address” of LibreOffice, and that the associated platform is Mastodon. The annotation about the platform could be done using Wikidata qualifiers.
Rename “Mastodon address” to “Fediverse account” since the @user@host is directly translateable to an acct: URI. “ActivityPub address” is inappropriate since ActivityPub does not require WebFinger, nor does it require such addresses.
If you want a predicate that implies “website account on”, then perhaps use “Fediverse profile” whose value is an https: URI to the profile page. Example: <trwnh> <has a Fediverse profile at> <https://mastodon.social/@trwnh>. Or “Fediverse account on” the web origin? <trwnh> <has a Fediverse account on> <https://mastodon.social>
I think that we could rename “Mastodon address” to “Fediverse account” without changing the Wikidata property identifier (P4033). However, this may loss some information about that these existing accounts were actually Mastodon accounts. To avoid this loss of information, we should edit all the existing occurrences of the property P4033 to add some qualifiers to the statements indicating that the system is Mastodon. For your case, the result could be the following:
"trwnh" # (the Q-name of you)
"fediverse account": "trwh@mastodon.social" # (a string)
"service software": "Mastodon" # (the Q-name of Maston, the software)
You are right, “website account on” is used to describe the server in a qualifier. For example,
"trwnh" # (the Q-name of you)
"website account on": "mastodon.social" # (the Q-name of mastodon.social)
"website username or ID": "trwh" # (a string)
"URL": "https://mastodon.social/@trwnh" # (an URL)
"service software": "Mastodon" # (the Q-name of Maston, the software)
Thus, if we follow the “website account on” pattern, we should include the qualifier “service software” if it does not already exist.
is the qualifier actually useful? Also, are we sure the data is clean enough for that and none of those accounts are really e.g. Misskey accounts with a mastodon like frontend?
IMO “Webfinger address” for the existing property and “ActivityPub URL” recommend for new accounts going forward is the right move, since the ecosystem is moving away from Webfinger
This is an excellent question. I would like to differentiate between a Mastodon account and a WordPress account with the ActivityPub plugin. Both may have a “Fediverse address.” Then, I would like to differentiate that one is for microblogging and the other for blogging. However, the border can get blurred, and sometimes may not depend on the software. I am not sure.
If we use “Fediverse address” instead of “Mastodon address,” then every Threads account will become automatically a Fediverse account, and we will not be able to differentiate between Mastodon accounts and Threads accounts. I think there is beneficial to differentiate Threads accounts from Mastodon accounts. Indeed, Wikidata already has a property for Threads accounts, which is the Instagram account. However, the types of values of these two types of accounts differ.
@nightpool, after reading you, I imagine another way to model this property. Maybe we should follow one of the suggestions by @trwnh, and not only rename the “Mastodon address” property P4033, but also the “Mastodon address” class Q124222109 and the “Mastodon instance” class Q72705885 as “Mastodon address” and “Fediverse instance,” respectively. However, I think we don’t need to rename these identities, but we can create more general elements such that these properties and classes inherit from.
Then, we should start defining the classes first. Maybe I am wrong, but I think that defining classes does not require an approval as defining properties does. So, perhaps we can start modeling the classes before modeling the properties.
To describe the Fediverse address, I used the Mastodon address property, but maybe this should be renamed to Fediverse address, as @trwnh suggested. The Mastodon classes, should be subclasses from the corresponding Fediverse classes above. Some modeling is needed. I will think about this tomorrow.
One thing you need to be careful about is that, while rare, the software running on a domain can change. So something that was once a “Mastodon service” might become an “Akkoma service” or a “Gotosocial service”.
In general, the way I think the data model would make logical sense is:
<trwnh>
<has a web profile> <https://mastodon.social/@trwnh> .
<https://mastodon.social/@trwnh>
<is a website account on> <https://mastodon.social> .
<https://mastodon.social>
<is a> <Mastodon Service> . # if this changes, update this one triple
<Mastodon Service>
<is a subclass of> <Fediverse Service> .
This can lead to some explosion of instances of Fediverse Service entities, but allows you to infer (with some additional equivalences) that by having a web profile that is a website account on https://mastodon.social which is itself a Mastodon Service and therefore also a Fediverse Service, that <trwnh> has a Fediverse account.
Yes, I think that is good to have many Fediverse services. They will be less than the Fediverse addresses. Also, using a Fediverse service class can be useful in terms of normalization because we can then describe the Fediverse service. Thus, instead of adding qualifiers to the statements “Alice has the Fediverse address alice@social.example.org” and “Bob has the Fediverse address bob@social.example.org,” we can characterize the Fediverse service entity for social.example.org.
Question: the class “Fediverse service” is similar (or a superclass) to the current “Mastodon instance.” Should we use the name “service” or “instance”?
One thing that we need to notice, is that Wikidata uses the Wikibase model, which differs from the RDF model. We have two ways to model that trwnh@mastodon.social belongs to a Mastodon service. I will use the prefixes Q, P, and PQ to denote entities, properties, and property qualifiers.
I prefer Model 1 because it avoids creating the entity Q-trwnh-at-mastodon.social. Creating a new entity for every Mastodon address is costly because each entity requires a Q-identifier and a page to be edited separately (i.e., losing context). In RDF, Model 2 would be more natural because it does not require annotating statements (the PQ-property is used to annotate a statement).
Another short thought regarding this question: When we save the email addresses of our contacts, we don’t care about the service provider they are using. In Fediverse, I think we care.
I think that we should include both the URL and the channel address (channel@example.com or @channel@example.com), since both could be useful in a different ways. People familiar with the fediverse will prefer the channel address, while people who are not on the fediverse would still be able to view the channel via the web.
Also, the fediverse is multi-protocol, despite the dominance of ActivityPub. So an optional field for protocol should be considered. For example, Hubzilla supports “zot, activitypub” (among others) which is listed in WebFinger.
Another thing to consider that Mastodon uses @channel@example.social while many other platforms omit the initial @ sign and use channel@example.social instead. We cannot assume that a platform uses a leading @ sign.
Another thing we should consider is bridging and the same account being available on multiple protocols.
For example, thanks to Bridgy Fed, I set up a single social media channel that is available on four different protocols.
ActivityPub: channel@example.social
Mastodon: @channel@example.social
Zot / Nomad: channel@example.social
Diaspora: channel@example.social
AT Protocol: @channel.example.social
P.S. I included Mastodon in the list, since they add an additional @ before their addresses and wanted to show that even within the fediverse, there are differences.
This is not a case of multiple accounts on different protocols. I have one account and post once, and my post is delivered to all of the above and all can interact with the same account.
Instead of creating a “fediverse address” maybe we should consider making something that is more universal.
The first question is whether we should consider Fediverse to include protocols other than ActivityPub. At least, all existing Fediverse protocol account addresses you mentioned include a pair consisting of a user and a domain name.
A second question is if we should make it more universal, and at what universality level. I guess that URLs are too universal. Are pairs user-domain a good compromise between universality and simplicity?
By the way, I received very interesting replies in this thread. So, I will summarize them all in a short report by the end of next week.
If you look at what is transmitted over ActivityPub, Webfinger, and other protocols, they typically use the URL to the person’s channel (social account) https://example.social/@user instead of, or in addition to, the channel address user@example.social.
So we also have to consider what format we want to have. A channel URL or a channel address, or both.
Using the URL might be safer, since it does not matter what protocol is being used. But there is an assumption that all fediverse accounts have a web URL (although, technically, it is an identifier, so it does not have to be resolvable).
The original fediverse did not use ActivityPub. Both Hubzilla and Mastodon are actually older than ActivityPub. And Hubzilla is multi-protocol. If we exclude projects because they don’t have ActivityPub turned on, we get this weird situation where one of the OG of the fediverse is not considered part of the fediverse.
And I am not sure we should even consider all ActivityPub platforms part of the fediverse. Do we consider Threads and WordPress part of the fediverse? I don’t know, but they use ActivityPub.
Regardless of definitions, the reality is that we have different protocols, and eventually they are going to connect and interact, either via multi-protocol platforms like Friendica and Hubzilla, or via bridges like Bridgy Fed. Either way, we should be prepared.
This is a good point for the discussion. I think we should consider other protocols than ActivityPub. If we do so, I am not sure what to do with the predicate. A use case is to find all universities with a Mastodon account. Currently, I can use the predicate mastodon addess to get the universities with an account on Mastodon (https://w.wiki/CLjK).
Those I was also working on describing instances. So, I defined the classes for instances of Pixelfed, WriteFreely, PeerTube, Lemmy, BookWyrm, and Friendica. I created this class following the existing class Mastodon instance description. Like the Mastodon instance class, all these classes are a subclass of the class Fediverse instance. With these classes, I was able to get the Fediverse instances in Latin America (instance https://w.wiki/ChB6).
Aliases (this account can be reached at other Addresses or URLs)
Platform (Mastodon, Hubzilla, Pixelfed, etc.)
Protocols (ActivityPub, Zot6, Nomad, Diaspora, AT Protocol, etc.)
Each field can be optional, but the more information they give, the better. Even if they just give the address or the URL or the DID, we should be able to look up that account.
Hopefully the platform provides information about what protocols are enabled. Hubzilla exposes this via webfinger.
A DID could be listed for platforms that support it.
Come to think of it, since the whole purpose of this is to be able to search for fediverse accounts, we might also want to add a type. It does not seem important now, but in the future, there will be at least three types of fediverse accounts: social, forums, and blogs. WordPress already has an ActivityPub plugin. And there are forums on the fediverse, and they behave differently than normal social accounts.
So it might be useful to have an optional field for type:
Type (social, forum, blog, etc.)
I am not sure what information you want to search for, other than what universities have a Mastodon account, but if we are creating a standard, we might as well make it extendable.