#fep_ef61 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #fep_ef61, aggregated by home.social.
-
Fediverse & P2P
Nomadic identity is a nice feature, but FEP-ef61: Portable Objects is not limited to that. The intention was always to allow peer to peer communication without servers. This is why the protocol was designed to be transport-agnostic: you can use fediverse servers to deliver activities, but you can also use emails, torrents or USB sticks.
To explore these possibilities, I added a simple P2P synchronization mode to Mitra Mini, which allows clients to exchange activities via a shared directory. This doesn't mean that clients should run on the same machine. Syncthing is a tool for P2P file synchronization that can be used to share a directory between multiple machines, and it should work well for our use case.
The P2P mode is available in Mitra Mini v0.4.0. You can use a pre-compiled binary, which is now self-contained and includes the mitra-web frontend. See installation instructions in the readme. To enable P2P mode, add the following block to your configuration file:
[federation] p2p_shared_outbox = "/path/to/shared/directory"Registering on a web gateway is not necessary when working in P2P mode, but you need to specify it in the config, because a lot of legacy code still depends on that.
If you'd like to connect, DM me your Syncthing device ID (it can be used in a Whonix VM to prevent IP address leaks).
-
Fediverse & P2P
Nomadic identity is a nice feature, but FEP-ef61: Portable Objects is not limited to that. The intention was always to allow peer to peer communication without servers. This is why the protocol was designed to be transport-agnostic: you can use fediverse servers to deliver activities, but you can also use emails, torrents or USB sticks.
To explore these possibilities, I added a simple P2P synchronization mode to Mitra Mini, which allows clients to exchange activities via a shared directory. This doesn't mean that clients should run on the same machine. Syncthing is a tool for P2P file synchronization that can be used to share a directory between multiple machines, and it should work well for our use case.
The P2P mode is available in Mitra Mini v0.4.0. You can use a pre-compiled binary, which is now self-contained and includes the mitra-web frontend. See installation instructions in the readme. To enable P2P mode, add the following block to your configuration file:
[federation] p2p_shared_outbox = "/path/to/shared/directory"Registering on a web gateway is not necessary when working in P2P mode, but you need to specify it in the config, because a lot of legacy code still depends on that.
If you'd like to connect, DM me your Syncthing device ID (it can be used in a Whonix VM to prevent IP address leaks).
-
Fediverse & P2P
Nomadic identity is a nice feature, but FEP-ef61: Portable Objects is not limited to that. The intention was always to allow peer to peer communication without servers. This is why the protocol was designed to be transport-agnostic: you can use fediverse servers to deliver activities, but you can also use emails, torrents or USB sticks.
To explore these possibilities, I added a simple P2P synchronization mode to Mitra Mini, which allows clients to exchange activities via a shared directory. This doesn't mean that clients should run on the same machine. Syncthing is a tool for P2P file synchronization that can be used to share a directory between multiple machines, and it should work well for our use case.
The P2P mode is available in Mitra Mini v0.4.0. You can use a pre-compiled binary, which is now self-contained and includes the mitra-web frontend. See installation instructions in the readme. To enable P2P mode, add the following block to your configuration file:
[federation] p2p_shared_outbox = "/path/to/shared/directory"Registering on a web gateway is not necessary when working in P2P mode, but you need to specify it in the config, because a lot of legacy code still depends on that.
If you'd like to connect, DM me your Syncthing device ID (it can be used in a Whonix VM to prevent IP address leaks).
-
FEP-ef61 now recommends semantic routing (FEP-ae49) for gateways: https://codeberg.org/fediverse/fep/pulls/840
-
@ValorZard No dice.
First of all, implementing nomadic identity would drastically alter the way how Mastodon works. It would make Mastodon, something that's supposed to be dead-simple, a great deal more complex.
I mean, in order to really pull this through all the way (as in Hubzilla/(streams)/Forte-level nomadic identity), your identity, your posts, your followers, your followed, your settings, your filters, your everything, all this must no longer directly reside in your account. It must be containerised in something that Hubzilla calls "channel", and that container would then reside in your account and be able to reside in multiple accounts on multiple independent servers.
Next, when Mastodon introduces a new feature, they tend to try to market it as their own original pioneering invention. They can't do that with nomadic identity. There are already enough people who know that nomadic identity was actually pioneered by Hubzilla before Mastodon even existed.
Furthermore, before Gargron implements something invented by Mike Macgirvin, hell will freeze over. Even if he tried to sell it as a unique feature of Mastodon, he'd still secretly have to admit that there's something that Mike did right. And quite a few eyes would be on him in hope of Mastodon getting more features from stuff created by Mike.
Ever heard of OpenWebAuth magic sign-on? Invented by Mike for Osada and Zap in the late 2010s, then backported to Hubzilla.
It was proposed for Mastodon, even if it was only client-side (as in, Mastodon logins would be detected by Hubzilla, (streams) and Forte, but Mastodon wouldn't be able to detect OpenWebAuth logins itself). This went as far as a merge request on GitHub. It could have been built into Mastodon. The code was literally there.
The merge request was silently rejected. And that would have been a fairly small change in comparison to the complete rebuild that'd be necessary for a full-blown, Forte-level, server-side implementation of nomadic identity.
I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon, what with every other Fediverse app being a Mastodon client. Mastodon would require a server-side implementation.
Seriously, it'd be easier to strap Mastodon's Web UI to Forte or Hubzilla with the necessary changes to adapt it to a vastly different backend.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity -
@@reiver ⊼ (Charles) :batman: @silverpill This is simply because little is written about Forte on the Web.
However, I was there when Forte was born back in September, 2024. I was on (streams) back then. Mike Macgirvin had implemented FEP-ef61 in the "nomad" branch of the streams repository a few months ago to test it. When he was confident enough, he merged the "nomad" branch into the regular "dev" branch. In July, 2024, he merged the "dev" branch into the "release" branch, causing the FEP-ef61 implementation to be rolled out to daily-driver (streams) servers.
However, it was a maze of Nomad and Zot6 and non-nomadic ActivityPub and FEP-ef61 identities for everything that boiled over. (streams) wouldn't federate with anything anymore, not even with itself. My two still existing (streams) channels, @Jupiter Rowland's (streams) outlet and @Jupiter's Fedi-Memes on (streams), were both affected by this. They were amongst the very first (streams) channels created on an account with FEP-ef61 DID support.
Mike would spend half of the summer trying to figure out what had happened and how to fix it. Even while (streams) was still broken, Forte was born in August, 2024 when Mike forked the streams repository and ripped all traces of Nomad and Zot6 support out, probably also in order to get rid of the corresponding IDs and facilitate debugging.
This means that FEP-ef61, which had literally caused this whole mayhem and which has to be considered responsible for Forte's very existence, was a) implemented in the streams repository when it was forked into Forte and b) not removed from Forte post-fork. It would not have made any sense to remove FEP-ef61 when one reason why Forte was made at that point in history was in order to debug FEP-ef61.
Sidenotes: Mike managed to fix (streams). This whole issue burned him out so much that he officially quit developing Fediverse software, effective September 1st, 2024, midnight. He still carries on working on both (streams) and Forte because nobody else does, what with how many people even use them.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #FEP_ef61 -
FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/773
Gateways can now remove integrity proofs from collections when they generate collection views. This enables filtering and pagination and is compatible with client-side signing (FEP-ae97).
-
@洪 民憙 (Hong Minhee) :nonbinary: Two people you may consider consulting in this case:
- @Mike Macgirvin ?️. He invented nomadic identity in 2011. He was the first to implement it in Red (which became Hubzilla in 2015) in 2012.
His streams repository, a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, is the place where he laid the foundations of FEP-ef61 out of necessity because he was working on nomadic identity via ActivityPub (Hubzilla and (streams) use their own protocols for that), and it was the first nomadic server software that had it implemented.
Also, his Forte, itself a fork of the streams repository, is the only Fediverse server software that uses nothing but ActivityPub to establish nomadic identity and relies on FEP-ef61 to do that. Basically, it's (streams) with no Nomad and Zot6 support, and syncing between clones is triggered by a cronjob because, unlike Zot6 and Nomad, ActivityPub doesn't provide any ways to trigger immediate, near-real-time syncs.
Mike hasn't been caught online for quite a while, though, although he's still working on both (streams) and Forte. - @silverpill is gradually turning Mitra from a typical non-nomadic, account/login-equals-identity, one-identity-per-account Fediverse software into something that's every bit as nomadic as Hubzilla, (streams) and Forte while casting everything necessary for this process into FEPs.
I'm not sure whether this will include containerising identities like the channels on Hubzilla, (streams) and Forte and allowing multiple fully independent identities on the same account, just like the same identity (channel) would be able to exist on independent accounts on different servers.
That said, is your goal only to use FEP-ef61 for identities that are tied to their accounts and their servers? Or is your goal fully-fledged nomadic identity on the same level as on Forte?
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Forte #Mitra #NomadicIdentity #FEP_ef61 - @Mike Macgirvin ?️. He invented nomadic identity in 2011. He was the first to implement it in Red (which became Hubzilla in 2015) in 2012.
-
@Marcus Rohrmoser 🌻 @Matthias @Lioh Das Problem ist, daß häufig der einzige Standard, an den sich Fediverse-Drittentwickler halten, Mastodon ist. Die bauen ihre Kreationen also nicht gegen als solche definierte Standards, sondern hart gegen Mastodon und nur gegen Mastodon. Vielfach wissen sie nicht mal, daß es außerhalb von Mastodon noch was anderes im Fediverse gibt.
So gehen sie dann felsenfest davon aus, daß jede Profil-URL im Fediverse so aussieht:https://server.tld/users/kurzname.
Und dann wundern sie sich, wenn sich Leute beschweren, daß ihre Kreation nicht mit $SERVERSOFTWARE funktioniert, von der sie noch nie etwas gehört haben.
Nur gibt's eben nicht nur Mastodon und Mastodon-Forks und Software, die gegen Mastodon gebaut wurde. Misskey ist älter als Mastodon, also sind Misskey und die Forkeys da anders aufgebaut. Friendica ist viel älter als Mastodon, also ist es wieder anders, ebenso seine Nachfahren.
A propos: Spätestens seit der Red Matrix, auf jeden Fall aber seit Hubzilla, wird unterschieden zwischen dem eigentlichen Kanal (mit dem Stream, wo man die Posts sieht, also z. B. https://hubzilla.org/channel/jupiter_rowland, und dem Profil, wo man die auch schon mal mehreren Dutzend Profilfelder sieht (wenn man das darf), aber keine Posts, also z. B. https://hubzilla.org/profile/jupiter_rowland. Der Kanal wird meines Wissens als Akteur erkannt, beim Profil bin ich mir nicht sicher.
Auf (streams) und Forte wird es noch wilder, weil die FEP-ef61 "Portable Objects" unterstützen und DIDs verwenden. Das war nötig, um nomadische Identität über ActivityPub zu unterstützen eine zukünftige nomadische Identität über mehrere Serveranwendungen hinweg vorzubereiten. Da gibt's dann- den Kanal
https://streams.elsmussols.net/channel/fedimemes_on_streams - das Profil
https://streams.elsmussols.net/profile/fedimemes_on_streams - den Kanal als DID
https://streams.elsmussols.net/.well-known/apgateway/did:key:z6Mkf2dhUa65zBYCNVqs3AHyt8uPixauZ7bPzEJn15LJANsd/actor
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NichtNurMastodon #Hubzilla #Streams #(streams) #Forte #FEP_ef61 - den Kanal
-
I am working on a new project, called minimitra.
It's a FEP-ae97 client that implements Mastodon API. Minimitra is similar to Mitra, but it is designed to run as a desktop application and supports portable accounts. That means: offline-first, full identity/data ownership, Tor/I2P friendly.
Currently minimitra can only send and receive public messages, but I expect that porting features will not be difficult because most of the code will be shared.
Other limitations / downsides:
- Requires postgresql server.
- Can't post to multiple gateways.
- No cross-client portability.Fortunately, all of that can be fixed!
-
@Strypey
That's a pretty major UX fail right there.
Any progress on finalising an FEP for using nomadic identity with AP?
I think it'll take more than that one FEP (FEP-ef61 Portable Objects) to do that. I expect @silverpill to whip up more FEPs in the on-going process of turning Mitra from something like most Fediverse software (non-nomadic, account equals identity) into something that's every bit as nomadic as Forte.
Thing is, Mitra still has a long way to go, also because it aims to have an implementation of nomadic identity that's entirely covered by FEPs. Forte has nomadic identity via ActivityPub, but that's technology adopted from Zot/Nomad that needed to be made to work first and foremost with no regards for FEPs.
Besides, the existence of FEPs doesn't matter as long as Mastodon refuses to adopt them. And Mastodon has already silently rejected client-side support for OpenWebAuth magic sign-on by refusing to merge an existing, ready-to-merge pull request that would have implemented it immediately.
This means we'll probably never even see Mastodon become capable of recognising nomadic channels. And I'm not talking about Mastodon going nomadic itself (which, by the way, would also give Mastodon the easy account moving that its users have been craving for for so long).
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Mitra #Forte #NomadicIdentity #FEP_ef61 -
FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/717
- Added a section explaining how to compare 'ap' URIs.
- Origin tuples are replaced with "cryptographic origins". The result is the same, but now we don't have to use port 0.
- Outboxes and FEP-ae97 are not required anymore. This means implementers can use a different activity synchronization mechanism. -
@Julian Fietkau I'm surprised to read that (streams) allegedly has FEP-e232 implemented. As I happen to have two (streams) channels myself, and as (streams) allows me to have a look at the whole source code of any activity (whereas Hubzilla only shows me that of the content), I've checked a fairly recent post of mine that includes a link. And while it does define the hashtags just like Mastodon and Hubzilla, it does not define links in a way that conforms to FEP-e232. Either that, or (streams)' implementation of FEP-e232 is newer than the software was when I sent that post.
Next, I wanted to see if (streams) had its way of quote-posting changed in the last seven years or so of development and forking. I expected it to quote-post like Hubzilla, namely by turning a BBcode short code into a dumb copy of the original upon sending, but I wanted to see proof. As (streams) is a fork of a fork of three forks of a fork (of a fork) of Hubzilla that's still maintained by Hubzilla's own creator, I would have been surprised if he had changed the way (streams) quote-posts at some point on the way.
So I quote-posted my own post on (streams) just to see what happens. And (streams) acted exactly like Hubzilla and not at all like described in FEP-044f on the surface. It still inserts a dumb copy.
Good thing I have access to the full source code of any message on (streams). So here's what happened, namely what I expected to happen: (streams) quote-posts like Hubzilla.
First of all, when I clicked the "Share" button, this short code was inserted into the post editor:[share=1198713][/share]
The number, by the way, is the running number of the message to quote-post on the server.
Upon sending the post, (streams) automatically "expanded" the short code into the dumb copy I had expected.[share author='Jupiter+Rowland' profile='https://hub.netzgemeinde.eu/channel/jupiter_rowland' portable_id='_moYLN61-o3FbP3jyThygMDf-bjF2cApXgkrwlAE77iKy19xM1_6F06V4b71eTkqqNaTUjGiN0lfw2dyn5nXRw' avatar='https://streams.elsmussols.net/xp/6b50efa4bb804860f6128bba791b74fab4a0a5e09dbcbee8d8ca77cee00f0330-6' link='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f' auth='true' posted='2025-09-21 19:42:56' message_id='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f'] ...(the source code of the original message goes here)... [/share]
Both Hubzilla and (streams) render this the same way, namely with a header line above the copy that includes the profile picture of the original author, the name of the original author with a Zot/Nomad-type link to their channel/account and a Zot/Nomad-type link to the original of the post ("Zot/Nomad-type" means that[zrl][/zrl]is used rather than[url][/url]which means that the ID of an observer on Hubzilla/(streams)/Forte is attached to the link for OpenWebAuth identity recognition purposes.)
At the same time, curiously, (streams) includes the line"rel": "https://misskey-hub.net/ns#_misskey_quote"and a line that starts with"name": "RE:and continues with the URL of the original message into the code for the link to the original message. The latter is identical to what Misskey and all Forkeys have in quote-posting notes in plain sight, only that (streams) only reveals it in the source code rather than in the content as well.
So this part of FEP-044f is implemented, albeit concealed from most people and only happening in the code.
Now, looking at the quote policy part, that looks like it could be possible to add to the Fediverse's permission champions Hubzilla, (streams) and Forte. After all, they already have comment controls with no FEP backing it (and if GoToSocial's quote policy can be made into an FEP, maybe so can (streams)' and Forte's comment controls so that they actually do blank out reply buttons on the farther ends of the Fediverse if the software on the farther ends implement support for that FEP).
This could be done at three levels again. I'll illustrate this with (streams) and Forte because they're quite a bit less complex than older Hubzilla.
At channel level, quote-posting (and maybe quoting as well) could be set as usually, namely to semi-public (= everyone in the Fediverse = no quote policy), restricted (= only your contacts) and only yourself. (Seriously, you don't want random passersby with no accounts to quote-post you. Even though you can allow them to comment on your posts if you dare.)
"Only yourself" could be overridden at contact level by permitting certain contacts to quote-post (and maybe quote) your messages. This is actually standard behaviour on (streams) and Forte.
And then there is the per-post level which would be similar to (streams)' and Forte's comment controls. These allow you to limit who may comment on a post to only your contacts and those who have already participated in the same conversation, and they allow you to turn off comments altogether.
Quote authorisation would not be much different in handling from manually moderating comments from those who technically aren't permitted to comment (only that spammers don't quote-post, at least not yet, and they probably never will because that simply makes no sense). So that'd be nothing really new.
Of course, this would have some limitations which come from how Hubzilla, (streams) and Forte work and from their conversation architecture.
The first limitation is that you could only give certain contacts permission to quote-post your posts if you didn't give it to the whole Fediverse. Channel-wide permissions are always inherited by contact-specific permissions, and this cannot be overridden. So you couldn't generally allow everyone to quote-post your posts except for one certain contact of yours.
The second limitation is that you can only control the permissions of contacts, but not of non-contacts. So you can't disallow some stranger whom you aren't connected to to quote-post your posts while everyone else is allowed.
Then again, FEP-044f doesn't make either of these two possible either. It can only define who is permitted to quote-post a post, not who isn't.
The third limitation is that, on Hubzilla, (streams) and Forte, comments always have the same permissions as the post that they belong to because comments always have the same owner as the post that they belong to. Basically, if FEP-044f was to be defined for each comment individually, it would have a chance of clashing with conversation containers as per FEP-171b.
Here on Hubzilla, as well as from (streams)' point of view, everyone's comments in this thread are owned by me because I've started the thread. And the permissions on all these comments are defined by my post. I've seen my share of permission clashes whenever someone on Mastodon replied to a public post or a public comment with a DM, and Hubzilla overrode this by forcing the permissions of the post on that reply.
In practice, this means that the quote policies of all comments would be the same as that of the post. At least that's how Hubzilla, (streams) and Forte would understand them because the concept of comments having different permissions than the post is alien to them. So if you say that I'm not permitted to quote-post your comment, but I say that anyone can quote-post my post, Hubzilla and (streams) override the quote policy that you've given your comment on Mastodon with the quote policy that I've given my post on Hubzilla, and I can quote-post you.
So the actually difficult part would be to implement an exception in how Hubzilla, (streams) and Forte handle comment permissions for quote policies and make them individual for each comment rather than making comments inherit them from the post.
Well, and lastly, if you permitted all your contacts to quote-post a post of yours, and you had a few more contacts, the"canQuote"section would end up monstrous. (A bit less so if you could cherry-pick those who are allowed to quote-post you on a per-post base, just like you can cherry-pick those who are allowed to see the post in the first place.) Also, I'm wondering just how well policies as per FEP-044f (and their implementations in various server applications) will work with DIDs as per FEP-ef61 which (streams) and Forte use, and I guess, so does Mitra now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Misskey #Forkey #Forkeys #GoToSocial #Hubzilla #Streams #(streams) #Forte #Mitra #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #Permission #Permissions #FEP_044f #FEP_171b #FEP_e232 #FEP_ef61 -
@Julian Fietkau I'm surprised to read that (streams) allegedly has FEP-e232 implemented. As I happen to have two (streams) channels myself, and as (streams) allows me to have a look at the whole source code of any activity (whereas Hubzilla only shows me that of the content), I've checked a fairly recent post of mine that includes a link. And while it does define the hashtags just like Mastodon and Hubzilla, it does not define links in a way that conforms to FEP-e232. Either that, or (streams)' implementation of FEP-e232 is newer than the software was when I sent that post.
Next, I wanted to see if (streams) had its way of quote-posting changed in the last seven years or so of development and forking. I expected it to quote-post like Hubzilla, namely by turning a BBcode short code into a dumb copy of the original upon sending, but I wanted to see proof. As (streams) is a fork of a fork of three forks of a fork (of a fork) of Hubzilla that's still maintained by Hubzilla's own creator, I would have been surprised if he had changed the way (streams) quote-posts at some point on the way.
So I quote-posted my own post on (streams) just to see what happens. And (streams) acted exactly like Hubzilla and not at all like described in FEP-044f on the surface. It still inserts a dumb copy.
Good thing I have access to the full source code of any message on (streams). So here's what happened, namely what I expected to happen: (streams) quote-posts like Hubzilla.
First of all, when I clicked the "Share" button, this short code was inserted into the post editor:[share=1198713][/share]
The number, by the way, is the running number of the message to quote-post on the server.
Upon sending the post, (streams) automatically "expanded" the short code into the dumb copy I had expected.[share author='Jupiter+Rowland' profile='https://hub.netzgemeinde.eu/channel/jupiter_rowland' portable_id='_moYLN61-o3FbP3jyThygMDf-bjF2cApXgkrwlAE77iKy19xM1_6F06V4b71eTkqqNaTUjGiN0lfw2dyn5nXRw' avatar='https://streams.elsmussols.net/xp/6b50efa4bb804860f6128bba791b74fab4a0a5e09dbcbee8d8ca77cee00f0330-6' link='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f' auth='true' posted='2025-09-21 19:42:56' message_id='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f'] ...(the source code of the original message goes here)... [/share]
Both Hubzilla and (streams) render this the same way, namely with a header line above the copy that includes the profile picture of the original author, the name of the original author with a Zot/Nomad-type link to their channel/account and a Zot/Nomad-type link to the original of the post ("Zot/Nomad-type" means that[zrl][/zrl]is used rather than[url][/url]which means that the ID of an observer on Hubzilla/(streams)/Forte is attached to the link for OpenWebAuth identity recognition purposes.)
At the same time, curiously, (streams) includes the line"rel": "https://misskey-hub.net/ns#_misskey_quote"and a line that starts with"name": "RE:and continues with the URL of the original message into the code for the link to the original message. The latter is identical to what Misskey and all Forkeys have in quote-posting notes in plain sight, only that (streams) only reveals it in the source code rather than in the content as well.
So this part of FEP-044f is implemented, albeit concealed from most people and only happening in the code.
Now, looking at the quote policy part, that looks like it could be possible to add to the Fediverse's permission champions Hubzilla, (streams) and Forte. After all, they already have comment controls with no FEP backing it (and if GoToSocial's quote policy can be made into an FEP, maybe so can (streams)' and Forte's comment controls so that they actually do blank out reply buttons on the farther ends of the Fediverse if the software on the farther ends implement support for that FEP).
This could be done at three levels again. I'll illustrate this with (streams) and Forte because they're quite a bit less complex than older Hubzilla.
At channel level, quote-posting (and maybe quoting as well) could be set as usually, namely to semi-public (= everyone in the Fediverse = no quote policy), restricted (= only your contacts) and only yourself. (Seriously, you don't want random passersby with no accounts to quote-post you. Even though you can allow them to comment on your posts if you dare.)
"Only yourself" could be overridden at contact level by permitting certain contacts to quote-post (and maybe quote) your messages. This is actually standard behaviour on (streams) and Forte.
And then there is the per-post level which would be similar to (streams)' and Forte's comment controls. These allow you to limit who may comment on a post to only your contacts and those who have already participated in the same conversation, and they allow you to turn off comments altogether.
Quote authorisation would not be much different in handling from manually moderating comments from those who technically aren't permitted to comment (only that spammers don't quote-post, at least not yet, and they probably never will because that simply makes no sense). So that'd be nothing really new.
Of course, this would have some limitations which come from how Hubzilla, (streams) and Forte work and from their conversation architecture.
The first limitation is that you could only give certain contacts permission to quote-post your posts if you didn't give it to the whole Fediverse. Channel-wide permissions are always inherited by contact-specific permissions, and this cannot be overridden. So you couldn't generally allow everyone to quote-post your posts except for one certain contact of yours.
The second limitation is that you can only control the permissions of contacts, but not of non-contacts. So you can't disallow some stranger whom you aren't connected to to quote-post your posts while everyone else is allowed.
Then again, FEP-044f doesn't make either of these two possible either. It can only define who is permitted to quote-post a post, not who isn't.
The third limitation is that, on Hubzilla, (streams) and Forte, comments always have the same permissions as the post that they belong to because comments always have the same owner as the post that they belong to. Basically, if FEP-044f was to be defined for each comment individually, it would have a chance of clashing with conversation containers as per FEP-171b.
Here on Hubzilla, as well as from (streams)' point of view, everyone's comments in this thread are owned by me because I've started the thread. And the permissions on all these comments are defined by my post. I've seen my share of permission clashes whenever someone on Mastodon replied to a public post or a public comment with a DM, and Hubzilla overrode this by forcing the permissions of the post on that reply.
In practice, this means that the quote policies of all comments would be the same as that of the post. At least that's how Hubzilla, (streams) and Forte would understand them because the concept of comments having different permissions than the post is alien to them. So if you say that I'm not permitted to quote-post your comment, but I say that anyone can quote-post my post, Hubzilla and (streams) override the quote policy that you've given your comment on Mastodon with the quote policy that I've given my post on Hubzilla, and I can quote-post you.
So the actually difficult part would be to implement an exception in how Hubzilla, (streams) and Forte handle comment permissions for quote policies and make them individual for each comment rather than making comments inherit them from the post.
Well, and lastly, if you permitted all your contacts to quote-post a post of yours, and you had a few more contacts, the"canQuote"section would end up monstrous. (A bit less so if you could cherry-pick those who are allowed to quote-post you on a per-post base, just like you can cherry-pick those who are allowed to see the post in the first place.) Also, I'm wondering just how well policies as per FEP-044f (and their implementations in various server applications) will work with DIDs as per FEP-ef61 which (streams) and Forte use, and I guess, so does Mitra now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Misskey #Forkey #Forkeys #GoToSocial #Hubzilla #Streams #(streams) #Forte #Mitra #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #Permission #Permissions #FEP_044f #FEP_171b #FEP_e232 #FEP_ef61 -
@Julian Fietkau I'm surprised to read that (streams) allegedly has FEP-e232 implemented. As I happen to have two (streams) channels myself, and as (streams) allows me to have a look at the whole source code of any activity (whereas Hubzilla only shows me that of the content), I've checked a fairly recent post of mine that includes a link. And while it does define the hashtags just like Mastodon and Hubzilla, it does not define links in a way that conforms to FEP-e232. Either that, or (streams)' implementation of FEP-e232 is newer than the software was when I sent that post.
Next, I wanted to see if (streams) had its way of quote-posting changed in the last seven years or so of development and forking. I expected it to quote-post like Hubzilla, namely by turning a BBcode short code into a dumb copy of the original upon sending, but I wanted to see proof. As (streams) is a fork of a fork of three forks of a fork (of a fork) of Hubzilla that's still maintained by Hubzilla's own creator, I would have been surprised if he had changed the way (streams) quote-posts at some point on the way.
So I quote-posted my own post on (streams) just to see what happens. And (streams) acted exactly like Hubzilla and not at all like described in FEP-044f on the surface. It still inserts a dumb copy.
Good thing I have access to the full source code of any message on (streams). So here's what happened, namely what I expected to happen: (streams) quote-posts like Hubzilla.
First of all, when I clicked the "Share" button, this short code was inserted into the post editor:[share=1198713][/share]
The number, by the way, is the running number of the message to quote-post on the server.
Upon sending the post, (streams) automatically "expanded" the short code into the dumb copy I had expected.[share author='Jupiter+Rowland' profile='https://hub.netzgemeinde.eu/channel/jupiter_rowland' portable_id='_moYLN61-o3FbP3jyThygMDf-bjF2cApXgkrwlAE77iKy19xM1_6F06V4b71eTkqqNaTUjGiN0lfw2dyn5nXRw' avatar='https://streams.elsmussols.net/xp/6b50efa4bb804860f6128bba791b74fab4a0a5e09dbcbee8d8ca77cee00f0330-6' link='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f' auth='true' posted='2025-09-21 19:42:56' message_id='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f'] ...(the source code of the original message goes here)... [/share]
Both Hubzilla and (streams) render this the same way, namely with a header line above the copy that includes the profile picture of the original author, the name of the original author with a Zot/Nomad-type link to their channel/account and a Zot/Nomad-type link to the original of the post ("Zot/Nomad-type" means that[zrl][/zrl]is used rather than[url][/url]which means that the ID of an observer on Hubzilla/(streams)/Forte is attached to the link for OpenWebAuth identity recognition purposes.)
At the same time, curiously, (streams) includes the line"rel": "https://misskey-hub.net/ns#_misskey_quote"and a line that starts with"name": "RE:and continues with the URL of the original message into the code for the link to the original message. The latter is identical to what Misskey and all Forkeys have in quote-posting notes in plain sight, only that (streams) only reveals it in the source code rather than in the content as well.
So this part of FEP-044f is implemented, albeit concealed from most people and only happening in the code.
Now, looking at the quote policy part, that looks like it could be possible to add to the Fediverse's permission champions Hubzilla, (streams) and Forte. After all, they already have comment controls with no FEP backing it (and if GoToSocial's quote policy can be made into an FEP, maybe so can (streams)' and Forte's comment controls so that they actually do blank out reply buttons on the farther ends of the Fediverse if the software on the farther ends implement support for that FEP).
This could be done at three levels again. I'll illustrate this with (streams) and Forte because they're quite a bit less complex than older Hubzilla.
At channel level, quote-posting (and maybe quoting as well) could be set as usually, namely to semi-public (= everyone in the Fediverse = no quote policy), restricted (= only your contacts) and only yourself. (Seriously, you don't want random passersby with no accounts to quote-post you. Even though you can allow them to comment on your posts if you dare.)
"Only yourself" could be overridden at contact level by permitting certain contacts to quote-post (and maybe quote) your messages. This is actually standard behaviour on (streams) and Forte.
And then there is the per-post level which would be similar to (streams)' and Forte's comment controls. These allow you to limit who may comment on a post to only your contacts and those who have already participated in the same conversation, and they allow you to turn off comments altogether.
Quote authorisation would not be much different in handling from manually moderating comments from those who technically aren't permitted to comment (only that spammers don't quote-post, at least not yet, and they probably never will because that simply makes no sense). So that'd be nothing really new.
Of course, this would have some limitations which come from how Hubzilla, (streams) and Forte work and from their conversation architecture.
The first limitation is that you could only give certain contacts permission to quote-post your posts if you didn't give it to the whole Fediverse. Channel-wide permissions are always inherited by contact-specific permissions, and this cannot be overridden. So you couldn't generally allow everyone to quote-post your posts except for one certain contact of yours.
The second limitation is that you can only control the permissions of contacts, but not of non-contacts. So you can't disallow some stranger whom you aren't connected to to quote-post your posts while everyone else is allowed.
Then again, FEP-044f doesn't make either of these two possible either. It can only define who is permitted to quote-post a post, not who isn't.
The third limitation is that, on Hubzilla, (streams) and Forte, comments always have the same permissions as the post that they belong to because comments always have the same owner as the post that they belong to. Basically, if FEP-044f was to be defined for each comment individually, it would have a chance of clashing with conversation containers as per FEP-171b.
Here on Hubzilla, as well as from (streams)' point of view, everyone's comments in this thread are owned by me because I've started the thread. And the permissions on all these comments are defined by my post. I've seen my share of permission clashes whenever someone on Mastodon replied to a public post or a public comment with a DM, and Hubzilla overrode this by forcing the permissions of the post on that reply.
In practice, this means that the quote policies of all comments would be the same as that of the post. At least that's how Hubzilla, (streams) and Forte would understand them because the concept of comments having different permissions than the post is alien to them. So if you say that I'm not permitted to quote-post your comment, but I say that anyone can quote-post my post, Hubzilla and (streams) override the quote policy that you've given your comment on Mastodon with the quote policy that I've given my post on Hubzilla, and I can quote-post you.
So the actually difficult part would be to implement an exception in how Hubzilla, (streams) and Forte handle comment permissions for quote policies and make them individual for each comment rather than making comments inherit them from the post.
Well, and lastly, if you permitted all your contacts to quote-post a post of yours, and you had a few more contacts, the"canQuote"section would end up monstrous. (A bit less so if you could cherry-pick those who are allowed to quote-post you on a per-post base, just like you can cherry-pick those who are allowed to see the post in the first place.) Also, I'm wondering just how well policies as per FEP-044f (and their implementations in various server applications) will work with DIDs as per FEP-ef61 which (streams) and Forte use, and I guess, so does Mitra now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Misskey #Forkey #Forkeys #GoToSocial #Hubzilla #Streams #(streams) #Forte #Mitra #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #Permission #Permissions #FEP_044f #FEP_171b #FEP_e232 #FEP_ef61 -
@Julian Fietkau I'm surprised to read that (streams) allegedly has FEP-e232 implemented. As I happen to have two (streams) channels myself, and as (streams) allows me to have a look at the whole source code of any activity (whereas Hubzilla only shows me that of the content), I've checked a fairly recent post of mine that includes a link. And while it does define the hashtags just like Mastodon and Hubzilla, it does not define links in a way that conforms to FEP-e232. Either that, or (streams)' implementation of FEP-e232 is newer than the software was when I sent that post.
Next, I wanted to see if (streams) had its way of quote-posting changed in the last seven years or so of development and forking. I expected it to quote-post like Hubzilla, namely by turning a BBcode short code into a dumb copy of the original upon sending, but I wanted to see proof. As (streams) is a fork of a fork of three forks of a fork (of a fork) of Hubzilla that's still maintained by Hubzilla's own creator, I would have been surprised if he had changed the way (streams) quote-posts at some point on the way.
So I quote-posted my own post on (streams) just to see what happens. And (streams) acted exactly like Hubzilla and not at all like described in FEP-044f on the surface. It still inserts a dumb copy.
Good thing I have access to the full source code of any message on (streams). So here's what happened, namely what I expected to happen: (streams) quote-posts like Hubzilla.
First of all, when I clicked the "Share" button, this short code was inserted into the post editor:[share=1198713][/share]
The number, by the way, is the running number of the message to quote-post on the server.
Upon sending the post, (streams) automatically "expanded" the short code into the dumb copy I had expected.[share author='Jupiter+Rowland' profile='https://hub.netzgemeinde.eu/channel/jupiter_rowland' portable_id='_moYLN61-o3FbP3jyThygMDf-bjF2cApXgkrwlAE77iKy19xM1_6F06V4b71eTkqqNaTUjGiN0lfw2dyn5nXRw' avatar='https://streams.elsmussols.net/xp/6b50efa4bb804860f6128bba791b74fab4a0a5e09dbcbee8d8ca77cee00f0330-6' link='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f' auth='true' posted='2025-09-21 19:42:56' message_id='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f'] ...(the source code of the original message goes here)... [/share]
Both Hubzilla and (streams) render this the same way, namely with a header line above the copy that includes the profile picture of the original author, the name of the original author with a Zot/Nomad-type link to their channel/account and a Zot/Nomad-type link to the original of the post ("Zot/Nomad-type" means that[zrl][/zrl]is used rather than[url][/url]which means that the ID of an observer on Hubzilla/(streams)/Forte is attached to the link for OpenWebAuth identity recognition purposes.)
At the same time, curiously, (streams) includes the line"rel": "https://misskey-hub.net/ns#_misskey_quote"and a line that starts with"name": "RE:and continues with the URL of the original message into the code for the link to the original message. The latter is identical to what Misskey and all Forkeys have in quote-posting notes in plain sight, only that (streams) only reveals it in the source code rather than in the content as well.
So this part of FEP-044f is implemented, albeit concealed from most people and only happening in the code.
Now, looking at the quote policy part, that looks like it could be possible to add to the Fediverse's permission champions Hubzilla, (streams) and Forte. After all, they already have comment controls with no FEP backing it (and if GoToSocial's quote policy can be made into an FEP, maybe so can (streams)' and Forte's comment controls so that they actually do blank out reply buttons on the farther ends of the Fediverse if the software on the farther ends implement support for that FEP).
This could be done at three levels again. I'll illustrate this with (streams) and Forte because they're quite a bit less complex than older Hubzilla.
At channel level, quote-posting (and maybe quoting as well) could be set as usually, namely to semi-public (= everyone in the Fediverse = no quote policy), restricted (= only your contacts) and only yourself. (Seriously, you don't want random passersby with no accounts to quote-post you. Even though you can allow them to comment on your posts if you dare.)
"Only yourself" could be overridden at contact level by permitting certain contacts to quote-post (and maybe quote) your messages. This is actually standard behaviour on (streams) and Forte.
And then there is the per-post level which would be similar to (streams)' and Forte's comment controls. These allow you to limit who may comment on a post to only your contacts and those who have already participated in the same conversation, and they allow you to turn off comments altogether.
Quote authorisation would not be much different in handling from manually moderating comments from those who technically aren't permitted to comment (only that spammers don't quote-post, at least not yet, and they probably never will because that simply makes no sense). So that'd be nothing really new.
Of course, this would have some limitations which come from how Hubzilla, (streams) and Forte work and from their conversation architecture.
The first limitation is that you could only give certain contacts permission to quote-post your posts if you didn't give it to the whole Fediverse. Channel-wide permissions are always inherited by contact-specific permissions, and this cannot be overridden. So you couldn't generally allow everyone to quote-post your posts except for one certain contact of yours.
The second limitation is that you can only control the permissions of contacts, but not of non-contacts. So you can't disallow some stranger whom you aren't connected to to quote-post your posts while everyone else is allowed.
Then again, FEP-044f doesn't make either of these two possible either. It can only define who is permitted to quote-post a post, not who isn't.
The third limitation is that, on Hubzilla, (streams) and Forte, comments always have the same permissions as the post that they belong to because comments always have the same owner as the post that they belong to. Basically, if FEP-044f was to be defined for each comment individually, it would have a chance of clashing with conversation containers as per FEP-171b.
Here on Hubzilla, as well as from (streams)' point of view, everyone's comments in this thread are owned by me because I've started the thread. And the permissions on all these comments are defined by my post. I've seen my share of permission clashes whenever someone on Mastodon replied to a public post or a public comment with a DM, and Hubzilla overrode this by forcing the permissions of the post on that reply.
In practice, this means that the quote policies of all comments would be the same as that of the post. At least that's how Hubzilla, (streams) and Forte would understand them because the concept of comments having different permissions than the post is alien to them. So if you say that I'm not permitted to quote-post your comment, but I say that anyone can quote-post my post, Hubzilla and (streams) override the quote policy that you've given your comment on Mastodon with the quote policy that I've given my post on Hubzilla, and I can quote-post you.
So the actually difficult part would be to implement an exception in how Hubzilla, (streams) and Forte handle comment permissions for quote policies and make them individual for each comment rather than making comments inherit them from the post.
Well, and lastly, if you permitted all your contacts to quote-post a post of yours, and you had a few more contacts, the"canQuote"section would end up monstrous. (A bit less so if you could cherry-pick those who are allowed to quote-post you on a per-post base, just like you can cherry-pick those who are allowed to see the post in the first place.) Also, I'm wondering just how well policies as per FEP-044f (and their implementations in various server applications) will work with DIDs as per FEP-ef61 which (streams) and Forte use, and I guess, so does Mitra now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Misskey #Forkey #Forkeys #GoToSocial #Hubzilla #Streams #(streams) #Forte #Mitra #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #Permission #Permissions #FEP_044f #FEP_171b #FEP_e232 #FEP_ef61 -
@Julian Fietkau I'm surprised to read that (streams) allegedly has FEP-e232 implemented. As I happen to have two (streams) channels myself, and as (streams) allows me to have a look at the whole source code of any activity (whereas Hubzilla only shows me that of the content), I've checked a fairly recent post of mine that includes a link. And while it does define the hashtags just like Mastodon and Hubzilla, it does not define links in a way that conforms to FEP-e232. Either that, or (streams)' implementation of FEP-e232 is newer than the software was when I sent that post.
Next, I wanted to see if (streams) had its way of quote-posting changed in the last seven years or so of development and forking. I expected it to quote-post like Hubzilla, namely by turning a BBcode short code into a dumb copy of the original upon sending, but I wanted to see proof. As (streams) is a fork of a fork of three forks of a fork (of a fork) of Hubzilla that's still maintained by Hubzilla's own creator, I would have been surprised if he had changed the way (streams) quote-posts at some point on the way.
So I quote-posted my own post on (streams) just to see what happens. And (streams) acted exactly like Hubzilla and not at all like described in FEP-044f on the surface. It still inserts a dumb copy.
Good thing I have access to the full source code of any message on (streams). So here's what happened, namely what I expected to happen: (streams) quote-posts like Hubzilla.
First of all, when I clicked the "Share" button, this short code was inserted into the post editor:[share=1198713][/share]
The number, by the way, is the running number of the message to quote-post on the server.
Upon sending the post, (streams) automatically "expanded" the short code into the dumb copy I had expected.[share author='Jupiter+Rowland' profile='https://hub.netzgemeinde.eu/channel/jupiter_rowland' portable_id='_moYLN61-o3FbP3jyThygMDf-bjF2cApXgkrwlAE77iKy19xM1_6F06V4b71eTkqqNaTUjGiN0lfw2dyn5nXRw' avatar='https://streams.elsmussols.net/xp/6b50efa4bb804860f6128bba791b74fab4a0a5e09dbcbee8d8ca77cee00f0330-6' link='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f' auth='true' posted='2025-09-21 19:42:56' message_id='https://hub.netzgemeinde.eu/item/0a1cdda5-eb1c-4a33-9574-ddd896977b4f'] ...(the source code of the original message goes here)... [/share]
Both Hubzilla and (streams) render this the same way, namely with a header line above the copy that includes the profile picture of the original author, the name of the original author with a Zot/Nomad-type link to their channel/account and a Zot/Nomad-type link to the original of the post ("Zot/Nomad-type" means that[zrl][/zrl]is used rather than[url][/url]which means that the ID of an observer on Hubzilla/(streams)/Forte is attached to the link for OpenWebAuth identity recognition purposes.)
At the same time, curiously, (streams) includes the line"rel": "https://misskey-hub.net/ns#_misskey_quote"and a line that starts with"name": "RE:and continues with the URL of the original message into the code for the link to the original message. The latter is identical to what Misskey and all Forkeys have in quote-posting notes in plain sight, only that (streams) only reveals it in the source code rather than in the content as well.
So this part of FEP-044f is implemented, albeit concealed from most people and only happening in the code.
Now, looking at the quote policy part, that looks like it could be possible to add to the Fediverse's permission champions Hubzilla, (streams) and Forte. After all, they already have comment controls with no FEP backing it (and if GoToSocial's quote policy can be made into an FEP, maybe so can (streams)' and Forte's comment controls so that they actually do blank out reply buttons on the farther ends of the Fediverse if the software on the farther ends implement support for that FEP).
This could be done at three levels again. I'll illustrate this with (streams) and Forte because they're quite a bit less complex than older Hubzilla.
At channel level, quote-posting (and maybe quoting as well) could be set as usually, namely to semi-public (= everyone in the Fediverse = no quote policy), restricted (= only your contacts) and only yourself. (Seriously, you don't want random passersby with no accounts to quote-post you. Even though you can allow them to comment on your posts if you dare.)
"Only yourself" could be overridden at contact level by permitting certain contacts to quote-post (and maybe quote) your messages. This is actually standard behaviour on (streams) and Forte.
And then there is the per-post level which would be similar to (streams)' and Forte's comment controls. These allow you to limit who may comment on a post to only your contacts and those who have already participated in the same conversation, and they allow you to turn off comments altogether.
Quote authorisation would not be much different in handling from manually moderating comments from those who technically aren't permitted to comment (only that spammers don't quote-post, at least not yet, and they probably never will because that simply makes no sense). So that'd be nothing really new.
Of course, this would have some limitations which come from how Hubzilla, (streams) and Forte work and from their conversation architecture.
The first limitation is that you could only give certain contacts permission to quote-post your posts if you didn't give it to the whole Fediverse. Channel-wide permissions are always inherited by contact-specific permissions, and this cannot be overridden. So you couldn't generally allow everyone to quote-post your posts except for one certain contact of yours.
The second limitation is that you can only control the permissions of contacts, but not of non-contacts. So you can't disallow some stranger whom you aren't connected to to quote-post your posts while everyone else is allowed.
Then again, FEP-044f doesn't make either of these two possible either. It can only define who is permitted to quote-post a post, not who isn't.
The third limitation is that, on Hubzilla, (streams) and Forte, comments always have the same permissions as the post that they belong to because comments always have the same owner as the post that they belong to. Basically, if FEP-044f was to be defined for each comment individually, it would have a chance of clashing with conversation containers as per FEP-171b.
Here on Hubzilla, as well as from (streams)' point of view, everyone's comments in this thread are owned by me because I've started the thread. And the permissions on all these comments are defined by my post. I've seen my share of permission clashes whenever someone on Mastodon replied to a public post or a public comment with a DM, and Hubzilla overrode this by forcing the permissions of the post on that reply.
In practice, this means that the quote policies of all comments would be the same as that of the post. At least that's how Hubzilla, (streams) and Forte would understand them because the concept of comments having different permissions than the post is alien to them. So if you say that I'm not permitted to quote-post your comment, but I say that anyone can quote-post my post, Hubzilla and (streams) override the quote policy that you've given your comment on Mastodon with the quote policy that I've given my post on Hubzilla, and I can quote-post you.
So the actually difficult part would be to implement an exception in how Hubzilla, (streams) and Forte handle comment permissions for quote policies and make them individual for each comment rather than making comments inherit them from the post.
Well, and lastly, if you permitted all your contacts to quote-post a post of yours, and you had a few more contacts, the"canQuote"section would end up monstrous. (A bit less so if you could cherry-pick those who are allowed to quote-post you on a per-post base, just like you can cherry-pick those who are allowed to see the post in the first place.) Also, I'm wondering just how well policies as per FEP-044f (and their implementations in various server applications) will work with DIDs as per FEP-ef61 which (streams) and Forte use, and I guess, so does Mitra now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Misskey #Forkey #Forkeys #GoToSocial #Hubzilla #Streams #(streams) #Forte #Mitra #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #Permission #Permissions #FEP_044f #FEP_171b #FEP_e232 #FEP_ef61 -
FEP-ae97: Client-side activity signing has been updated: https://codeberg.org/fediverse/fep/pulls/682
I added a new section describing Media API after implementing it in Mitra v4.10.0.
The API is somewhat similar to Blossom API used by Nostr apps: media objects are identified by their SHA-256 digests, and can be mirrored to other gateways.
I also specified status codes for error responses.
-
Notes on the implementation of Data Portability in #tootik
https://github.com/dimkr/tootik/blob/v0.19.0/FEDERATION.md#data-portability
-
#tootik implemented FEP-ef61
We have 3 independent implementations now:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#status
@dimkr #fep_ef61 #NomadicIdentity
RE: https://hd.206267.xyz/post/0198d701-8bdd-71f2-bd56-9f381e18f15f
-
I've made several changes to FEP-ef61: Portable Objects
https://codeberg.org/fediverse/fep/pulls/668
Section "Authentication and authorization" explains the differences between portable objects and non-portable objects (FEP-fe34):
- Cryptographic origins are used instead of RFC-6454 web origins.
- Portable objects can't be fetched from their origins.Activities delivered to an inbox MUST NOT be forwarded more than once (to avoid infinite loop). Requirements related to outbox implementation has been clarified.
Gateways SHOULD implement FEP-ae97 actor registration process (previously it was MAY).
-
@Ben Pate 🤘🏻
I've looked through FEP-ef61 in the past, and will give it another go. I think I struggled to see how this would be compatible with Mastodon, or other servers without them requiring a pretty big rewrite to support portable objects.
It won't. Especially not with Mastodon.
At the very least, they would have to start to understand portable objects and the concept of nomadic identity, e.g. that[email protected]and[email protected]may be on two different accounts, but the exact same channel with the exact same identity, the exact same connections, the exact same content etc.
Mastodon has been flipping the bird both at the ActivityPub standard and at FEPs and at the whole rest of the Fediverse since it was made. Eugen Rochko has been trying to EEE the Fediverse since he created Mastodon, the very same thing that people on Mastodon feared that Threads would do. The only time he ever makes compromises is when he is put under pressure by even more powerful players like Automattic or Flipboard, and even then he only throws them tiny bones.
As @Mike Macgirvin ?️ gradually built his nomadic and ActivityPub-based Forte from his own nomadic and Nomad-based streams repository (itself a Hubzilla descendant), and as @silverpill started making his non-nomadic and ActivityPub-based Mitra nomadic, their goal was to expand ActivityPub into something that supports nomadic identity via FEPs and, at the same time, make their own software compatible to these FEPs.
Their goal was not to make their software and these FEPs fully compatible with the Fediverse as it was in 2023/2024 and especially not to build them against Mastodon as it was in 2023/2024 or as it is now.
Especially Mike would never build anything explicitly against Mastodon. Rather, he'd make it possible to block Mastodon from an entire (streams) or Forte server, and he did. To Mike, Mastodon is not the heart and the core and the centre of the Fediverse around everything else orbits and justifiedly so. He rather sees it as a nuisance.
Seriously, nothing that Mike has created will ever be fully compatible with Mastodon, not as long as Mastodon's politics don't change greatly. I mean, client-side support for Mike's own OpenWebAuth magic sign-on was proposed for Mastodon. It went as far as an actual merge request in 2023. They core devs never even looked at that merge request, much less merged it. They silently rejected it.
@Contraquestão
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #NomadicIdentity #FEP_ef61 -
Added Nomadic ActivityPub page to the ap-next repository:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md
This is a brief summary of the work we've done. Feedback is welcome!
-
FEP-ef61 "Portable Objects" update:
https://codeberg.org/fediverse/fep/pulls/529
The role of decentralized identifiers in FEP-ef61 is similar to "servers" in vanilla ActivityPub: they control all actors within a certain namespace.
When multiple actors exist under DID's authority, they will likely use same gateways. I added a sentence saying that gateways can be advertised via DID document as DID services (an example of that can be found in did:fedi spec). This is not possible withdid:key, but might be useful with other DID methods.
I am also considering movinggatewaysproperty to actor'sendpointsmapping, where server-wide endpoints such assharedInboxare usually defined (in our case they are "DID-wide"). -
I updated "Authentication and authorization" section of FEP-ef61 (Portable objects): https://codeberg.org/fediverse/fep/pulls/497.
Authentication requirements in FEP-ef61 differ depending on the object class. Actors, activities and objects must always be signed (i.e. have an integrity proof). Signing collections may be impractical, so we make an exception for them, and trust the gateway if that gateway is trusted by actor. Links are not supposed to have an
id, and there is no requirement to sign them.This would not be possible without FEP-2277 which provides a classification of ActivityPub objects based on their shape.
FEP-2277 also got a small update. The algorithm now gives Link a higher priority: https://codeberg.org/fediverse/fep/pulls/496
-
@cy
The people who wrote the Fediverse
There were no "people who wrote the Fediverse". These was no committee who laid down the standards.
The Fediverse was invented by @Evan Prodromou. In 2008. By first creating a centralised Twitter alternative silo named Identi.ca.
And then open-sourcing the underlying technology as Laconi.ca, later StatusNet (merged into GNU social in 2013).
And then laying the protocol open as OpenMicroBlogging, later superseded by OStatus.
Then, in 2010, @Mike Macgirvin ?️ decided that the world needs a free, open-source, decentralised, secure alternative to Facebook that's better than Facebook. And so he made Mistpark, today Friendica.
But the features he wanted Friendica to have were impossible to achieve with any existing protocol. OStatus wasn't even that good for microblogging, much less Mike's ambitious plans. Besides, he's an experienced protocol designer. So he created a whole new protocol, DFRN, and built Friendica on top of it. Friendica did adopt OStatus as an extra protocol, though, because Friendica's goal was and still is to federate with everything and then some.
In 2011, Mike had seen many public Friendica nodes shut down with or without warning and people always losing everything and having to start over from scratch. So he decided to do something against it.
He invented nomadic identity. And built a new protocol around it, Zot, because there was no way DFRN could take care of this, let alone OStatus.
In 2012, he forked Friendica into Red and rewrote the whole backend against Zot, which, however, required the creation of yet another identity scheme.
For one, one login could now have multiple fully separate and independent identities on it. For example, my Hubzilla channel URL is https://hub.netzgemeinde.eu/channel/jupiter_rowland.
Besides, one identity could now reside on multiple server instances which is what nomadic identity means.
Red was later renamed Red Matrix and, in 2015, refactored, redesigned and renamed into Hubzilla.
Mastodon and Pleroma started in 2016 as OStatus-based alternative UIs for GNU social. Mastodon was the first to be turned into a stand-alone project with not much interest in connecting to anything outside, all in spite of already being federated with Pleroma, GNU social, Friendica and Hubzilla via OStatus.
ActivityPub came out in 2017. No, not 2018. It was standardised in 2018. But it came out in 2017.
In July, 2017, Hubzilla was the first Fediverse project to integrate ActivityPub. Next to its own Zot, next to diaspora*, next to OStatus etc. On the one hand, Hubzilla tried to stay as close to the ActivityPub spec as possible and feasible. On the other hand, Hubzilla had to make its ActivityPub integration, which has always been an optional add-on, compatible to its own technology, to its own Zot protocol, to the way it works.
In September, Mastodon was the second Fediverse project to adopt ActivityPub. But Mastodon was more interested in doing its own thing and being as close to Twitter as it could than in sticking to a protocol spec, much less connecting to non-Mastodon stuff such as Hubzilla with which it already shared two protocols now.
Mastodon was the one that added Webfinger. ActivityPub doesn't even require Webfinger. The ActivityPub spec doesn't contain Webfinger. But Mastodon requires Webfinger. It can't live without Webfinger. So everything that wants to properly federate with Mastodon needs to implement Webfinger.
After ActivityPub had become a standard, more projects adopted it. But as lax a specification as ActivityPub is, it allowed for a lot of liberties.
Some devs looked at how Mastodon had integrated ActivityPub, decided it was rubbish and did it their own way.
Some devs looked at how Mastodon had integrated ActivityPub, decided they couldn't do it the same way because what they did was too different from Mastodon and did it their own way.
Some devs didn't look at what anyone else did and did it their own way.
Probably none of them looked at how Hubzilla had integrated ActivityPub because none of them even knew that Hubzilla existed. Except for those who were maintaining Friendica now. And Friendica had to make it compatible with DFRN and with the way it had been working since 2010.
Fast-forward to 2023. Mike's current piece of work was the streams repository which contains an intentionally nameless fork of a fork of three forks of a fork (of a fork) of Hubzilla, slimmed down from Hubzilla, but modernised and technologically even more advanced.
It was then that @silverpill, creator and maintainer of Mitra, got into contact with him because he wanted to add nomadic identity to Mitra. Something that's built on ActivityPub and only supports ActivityPub. A first. No-one had ever done nomadic identity with nothing but ActivityPub before.
So the two started working on how to implement nomadic identity using only ActivityPub. Mike had a vision of a Fediverse with nomadic identity all over and Fediverse identities cloned beyond server application borders. Like, a (streams) channel cloned to Mitra, Mastodon, PeerTube and Mobilizon, all with the same identity.
This, however, required another, brand-new way of identifying Fediverse actors. And so FEP-ef61 "Portable Objects" was created.
We're probably in the middle of xkcd 927 now.
Mike set up an experimental branch of (streams) to develop and test nomadic identity via ActivityPub, also since (streams) already had nomadic identity anyway.
Around summer, the "nomadic" branch (for nomadic identity via ActivityPub) seemed reliable enough to merge it into "dev". And in July, "dev" was merged into "release", complete with nomadic-identity-via-ActivityPub code.
It was shortly after that merge that I created my two (streams) channels. The channel URL of my channel for Fediverse memes is https://streams.elsmussols.net/channel/fedimemes_on_streams. But its DID, which all channels created on accounts registered after that merge got, is https://streams.elsmussols.net/.well-known/apgateway/did:key:z6Mkf2dhUa65zBYCNVqs3AHyt8uPixauZ7bPzEJn15LJANsd/actor. And that's only two IDs of the same channel. There are also others for (streams)' native Nomad protocol, Hubzilla's Zot6 protocol, ActivityPub, OAuth, OAuth2 and probably also OpenWebAuth magic single sign-on, another one of Mike's creations. Not to mention that (streams) channels, like Hubzilla channels and Friendica accounts, can also optionally be group actors.
In fact, this blew up into (streams) users' faces because (streams) confused the various IDs to such degrees that it wouldn't federate at all anymore. It took Mike a whole lot of work to iron this out again, so much that he officially retired from Fediverse development on August 31st.
And in the middle of this, he even created yet another fork, Forte, which is (streams) minus Nomad, minus Zot6, based on and supporting only ActivityPub. My guess is still that one of the reasons to create Forte at that point was to get rid of the Nomad and Zot6 IDs to sort the ID mess out.
Even if nomadic identity via ActivityPub should ever become stable and start spreading, I don't expect DIDs to become the one norm in the Fediverse. Not with all those barely or unmaintained projects and those devs who refuse to acknowledge that devs of other projects do great stuff, too.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #OStatus #DFRN #Zot #ActivityPub #Nomad #Laconi.ca #Identi.ca #StatusNet #GNUsocial #Friendica #Hubzilla #Mastodon #Pleroma #Streams #(streams) #Forte #FEP_ef61 -
Today, on the anniversary of publishing FEP-ef61, nomadic actors on Streams and Mitra made their first contact.
I created a signed
Followactivity using the nomadic client and sent it to the Mitra gateway, which delivered activity to a nomadic actor on the Streams server. The Streams actor sent anAcceptactivity back, which I then picked from my inbox on the gateway. -
FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/455
I added a couple of sentences clarifying FEP-ef61 design goals. In particular:
1. "This document describes web gateways, which use HTTP transport. However, the data model and authentication mechanism are transport-agnostic and other types of gateways could exist."
FEP-ef61 is designed to be compatible with any transport protocol, including the sneakernet. For example, it should be possible to replace web gateways with iroh nodes.
2. Location discovery using DID services. It came to my attention that some developers are trying to implement a variation of FEP-ef61 where gateways are specified in a DID document instead of an actor document. That significantly differs from existing FEP-ef61 implementations (Streams and Mitra), and has a serious practical disadvantage: it doesn't work with generative DID methods such as
did:key. Support for pure key-based identities is important for several reasons:- It is very useful for client-to-client (#p2p) communication without servers.
- Interoperability with other protocols that use public keys as identities. #Nostr is probably the most popular, but there are many more.
- It lowers the barriers to entry for client developers, who otherwise would need to deploy a did:web or something more complicated like did:webvh.So, don't do that.
Also added a discussion section about media access control.
If media identifier only contains a digest, the gateway can't restrict access to it. This may not be a big problem because digest is very hard to guess, but an access control mechanism still might be useful. One way to implement it is to add an 'ap' identifier of a parent document to a hashlink and make it mandatory.
-
Access control would require additional information to be encoded in hashlink URI (in its metadata component). I think it should be the 'ap' ID of the containing object. Perhaps it should be even mandatory, because there is no good reason to store random files on a FEP-ef61 gateway.
-
FEP-ef61 update: I've added a description of integrity protection mechanism for media.
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#media
It is now recommended to add
digestMultibaseproperty to objects representing images and other external resources, and hashlinks are recommended for references (because they are also based on multihashes).Adding
digestMultibaseis a good idea even if object is not portable. That allows recipients to verify integrity of a file when it is served by a 3rd party, and makes it possible for them do skip download if they already have a copy. -
FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/447
The most important change here is a switch from FEP-c7d3 to FEP-fe34. An algorithm for computing origin of a DID URL has been specified, so now it is possible to do this:
is_same_origin(id, proof.verificationMethod) -
@Jenniferplusplus I sincerely hope that you aren't building Letterbook to only interact with itself and Mastodon.
Sooner or later, Letterbook will encounter content coming in from instances of software created by @Mike Macgirvin ?️, namely Friendica, Hubzilla (these two are actually older than Mastodon), (streams) or Forte. For reference: I am on Hubzilla.
You/it will have to expect and be able to deal with the following:- Enclosed one-post-many-comments conversations instead of threads that consist of posts loosely tied together
- Permissions of all comments/replies firmly defined by the start post; permissions/visibility can't be changed within a running conversation
- "Monster posts" of any length because none of them has a character limit
- Not just Note-type objects, but also Article-type objects (from Friendica right now, the others may implement them once Mastodon introduces sensible support for them)
- Full HTML text formatting, up to and including numbered lists, tables, horizontal lines, character size and character colour
- Both quotes (as done in bulletin-board forums) and quote-posts (posts fully embedded in other posts like quote-tweets)
- Embedded links (this comment makes a whole lot of use of them)
- Inline images embedded within the text, and more than four of these in one post
- Inline audio streams embedded within the text
- Inline videos embedded within the text
- "Weird" mentions and hashtags with the @ or the # not part of the link (look at the mentions and the hashtags in this comment, then look at mentions and hashtags on Mastodon and compare them)
- "Summaries in the CW field" (because Mastodon repurposed StatusNet's summary field, which was used by StatusNet, Friendica and Hubzilla as an actual summary field, for content warnings in 2017; several Fediverse server apps continue to use it for summaries)
- All four support titles in addition to summaries
Some of the above may also come in from elsewhere, e.g. a wider range of text formatting than Mastodon allows itself to render is fully supported by just about everything that isn't Mastodon.
Also, ActivityPub is currently evolving. New FEPs are being put to use and bringing in new features far away from how Mastodon is working. In particular, (streams) and Forte and @silverpill's Mitra use decentralised identifiers as per FEP-ef61 (Portable Objects). Forte has nomadic identity fully implemented via ActivityPub while (streams) at least supports it. And all three have conversation containers implemented, silverpill wants to make them an FEP, and Hubzilla is planning to implement them with version 10.
This means three things. One, weird identifiers. Two, weird actor identities: What looks like one user automatically cross-posting to another account on another instance to non-nomadic ActivityPub implementations is actually the very same actor residing simultaneously on multiple server instances. Three, again, conversations work drastically different from Twitter and Mastodon.
Lastly, it may be a good idea to implement a little server type display from the get-go so that the user knows what kind of Fediverse instance something comes from. Misskey and its forks have it, Friendica has it, (streams) has it, Forte has it. Just because Mastodon doesn't have it, doesn't mean it's a good idea not to have it. Besides, if content from certain server applications malfunctions on Letterbook, users can pinpoint right away what server application causes that trouble when submitting a bug report.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #Conversations #ConversationContainers #FEP_ef61 #NomadicIdentity -
@glyn There is no spec for nomadic identity itself AFAIK. In the Zot6 and Nomad protocols, it simply is part of the protocols.
What there is is limited to:- the specification of the Zot6 protocol as implemented in Hubzilla
- the specification of the Nomad protocol (would be Zot12 if it was still compatible with Zot6) as implemented in (streams)
- ActivityPub FEPs, especially FEP-ef61 Portable Objects which implements Decentralized Identifiers as suggested by the W3C
Nomadic identity via ActivityPub is still very experimental and far from finalised. According to Mike Macgirvin, it is implemented in the streams repository and at least theoretically operational. But of the few (streams) users, nobody makes use of it, also because Nomad, which itself provides nomadic identity, is still (streams)' primary protocol whereas ActivityPub is optional. So when a (streams) channel is cloned, it's always cloned via Nomad.
His recent fork of the streams repository, a project named Forte, is basically (streams) without Nomad and Zot6 support, entirely based on ActivityPub, and thus the first publicly available ActivityPub-based Fediverse server software with nomadic identity.
But Forte itself is still seen as experimental. Even of the few (streams) users, nobody dares to test-drive it, also to let Mike go on tinkering with it without having to take care of support for instance admins or even users. Since Mike is officially retired and has slowed down his software development dramatically, things will probably stay this way for quite a long time. In fact, Mike himself is still running his own channels on (streams), so there isn't a single Forte server, much less channel, in productive use.
Last but not least, there is Mitra by @silverpill, the only Fediverse software not developed by Mike Macgirvin that is working on implementing nomadic identity. FEP-ef61 is implemented in release code, but full-blown nomadic identity only exists in a non-public development branch.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #DecentralisedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Nomad #Hubzilla #Streams #(streams) #Mitra -
@Strypey A few more details:
* FEP-ef61: Portable Objects
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Invented in, I think, 2023 by @silverpill for Mitra (based on ActivityPub). Currently implemented there and in @Mike Macgirvin ?️'s streams repository and Forte. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub.* FEP-61cf: The OpenWebAuth Protocol
https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually.
CC: @Laurens Hof
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #Zot #Zot6 #Nomad #ActivityPub #FEP #FEP_ef61 #FEP_61cf #DecentralizedIdentity #NomadicIdentity #OpenWebAuth #SingleSignOn -
@Strypey A few more details:
* FEP-ef61: Portable Objects
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Invented in, I think, 2023 by @silverpill for Mitra (based on ActivityPub). Currently implemented there and in @Mike Macgirvin ?️'s streams repository and Forte. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub.* FEP-61cf: The OpenWebAuth Protocol
https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually.
CC: @Laurens Hof
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #Zot #Zot6 #Nomad #ActivityPub #FEP #FEP_ef61 #FEP_61cf #DecentralizedIdentity #NomadicIdentity #OpenWebAuth #SingleSignOn -
@Strypey A few more details:
* FEP-ef61: Portable Objects
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Invented in, I think, 2023 by @silverpill for Mitra (based on ActivityPub). Currently implemented there and in @Mike Macgirvin ?️'s streams repository and Forte. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub.* FEP-61cf: The OpenWebAuth Protocol
https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually.
CC: @Laurens Hof
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #Zot #Zot6 #Nomad #ActivityPub #FEP #FEP_ef61 #FEP_61cf #DecentralizedIdentity #NomadicIdentity #OpenWebAuth #SingleSignOn -
@Strypey A few more details:
* FEP-ef61: Portable Objects
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Invented in, I think, 2023 by @silverpill for Mitra (based on ActivityPub). Currently implemented there and in @Mike Macgirvin ?️'s streams repository and Forte. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub.* FEP-61cf: The OpenWebAuth Protocol
https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually.
CC: @Laurens Hof
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #Zot #Zot6 #Nomad #ActivityPub #FEP #FEP_ef61 #FEP_61cf #DecentralizedIdentity #NomadicIdentity #OpenWebAuth #SingleSignOn -
@Strypey A few more details:
* FEP-ef61: Portable Objects
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Invented in, I think, 2023 by @silverpill for Mitra (based on ActivityPub). Currently implemented there and in @Mike Macgirvin ?️'s streams repository and Forte. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub.* FEP-61cf: The OpenWebAuth Protocol
https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually.
CC: @Laurens Hof
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #Zot #Zot6 #Nomad #ActivityPub #FEP #FEP_ef61 #FEP_61cf #DecentralizedIdentity #NomadicIdentity #OpenWebAuth #SingleSignOn -
'ap' URLs are not valid URIs according to RFC-3986. FEP-ef61 describes a possible solution: percent-encode a DID (the authority component of an 'ap' URL)
Today I found another solution. RFC-3986 allows future, as-yet-undefined IP literal address formats if they are enclosed in square brackets and prefixed with a version flag.
For example, this is a valid URI:
ap://[vd.did:key:z6MkvUie7gDQugJmyDQQPhMCCBfKJo7aGvzQYF2BqvFvdwx6]/objects/123 -
@glyn Decentralised identity has been available for longer than Mastodon, let alone ActivityPub. Only that it is known as "nomadic identity" here.
It was first implemented by Friendica creator @Mike Macgirvin ?️ in the Zot protocol in 2011 and in a Friendica fork named Red in 2012, later renamed into the Red Matrix, eventually reworked and renamed into Hubzilla in 2015.
Proof: This Hubzilla channel of mine actually simultaneously resides on two servers.
(Almost) everything that Mike has made afterwards, forks and forks of forks of Hubzilla, used to have or still have nomadic identity implemented.
His streams repository contains a fork of a fork... of Hubzilla that intentionally has no name, and that offers nomadic identity via the Nomad protocol with better compatibility with non-nomadic ActivityPub. In July, it had decentralised IDs as per FEP-ef61 (see also here) implemented, a first step by Mike to fully implement nomadic identity in ActivityPub.
Forte, Mike's most recent fork from August, had all support for Nomad and Zot6 removed and only uses ActivityPub anymore while still offering nomadic identity. To my best knowledge, however, it has yet to be declared stable enough to be daily-driven, and it has no public instances.
Other than all this, a non-public development version of @silverpill's Mitra has nomadic identity via ActivityPub in development. I'm not sure whether FEP-ef61 is implemented in the release version yet. It's the only Fediverse project aiming to implement nomadic identity which Mike Macgirvin has nothing directly to do with.
The ultimate goal is to be able to clone a Fediverse identity across project borders. Only considering stable releases, it's currently only possible to clone Hubzilla channels within Hubzilla, using Zot6, or (streams) channels within (streams), using Nomad.
Unfortunately, Mike has officially retired from Fediverse development and only occasionally submits code to the streams repository and Forte anymore.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Mitra -
@glyn Decentralised identity has been available for longer than Mastodon, let alone ActivityPub. Only that it is known as "nomadic identity" here.
It was first implemented by Friendica creator @Mike Macgirvin ?️ in the Zot protocol in 2011 and in a Friendica fork named Red in 2012, later renamed into the Red Matrix, eventually reworked and renamed into Hubzilla in 2015.
Proof: This Hubzilla channel of mine actually simultaneously resides on two servers.
(Almost) everything that Mike has made afterwards, forks and forks of forks of Hubzilla, used to have or still have nomadic identity implemented.
His streams repository contains a fork of a fork... of Hubzilla that intentionally has no name, and that offers nomadic identity via the Nomad protocol with better compatibility with non-nomadic ActivityPub. In July, it had decentralised IDs as per FEP-ef61 (see also here) implemented, a first step by Mike to fully implement nomadic identity in ActivityPub.
Forte, Mike's most recent fork from August, had all support for Nomad and Zot6 removed and only uses ActivityPub anymore while still offering nomadic identity. To my best knowledge, however, it has yet to be declared stable enough to be daily-driven, and it has no public instances.
Other than all this, a non-public development version of @silverpill's Mitra has nomadic identity via ActivityPub in development. I'm not sure whether FEP-ef61 is implemented in the release version yet. It's the only Fediverse project aiming to implement nomadic identity which Mike Macgirvin has nothing directly to do with.
The ultimate goal is to be able to clone a Fediverse identity across project borders. Only considering stable releases, it's currently only possible to clone Hubzilla channels within Hubzilla, using Zot6, or (streams) channels within (streams), using Nomad.
Unfortunately, Mike has officially retired from Fediverse development and only occasionally submits code to the streams repository and Forte anymore.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Mitra -
@glyn Decentralised identity has been available for longer than Mastodon, let alone ActivityPub. Only that it is known as "nomadic identity" here.
It was first implemented by Friendica creator @Mike Macgirvin ?️ in the Zot protocol in 2011 and in a Friendica fork named Red in 2012, later renamed into the Red Matrix, eventually reworked and renamed into Hubzilla in 2015.
Proof: This Hubzilla channel of mine actually simultaneously resides on two servers.
(Almost) everything that Mike has made afterwards, forks and forks of forks of Hubzilla, used to have or still have nomadic identity implemented.
His streams repository contains a fork of a fork... of Hubzilla that intentionally has no name, and that offers nomadic identity via the Nomad protocol with better compatibility with non-nomadic ActivityPub. In July, it had decentralised IDs as per FEP-ef61 (see also here) implemented, a first step by Mike to fully implement nomadic identity in ActivityPub.
Forte, Mike's most recent fork from August, had all support for Nomad and Zot6 removed and only uses ActivityPub anymore while still offering nomadic identity. To my best knowledge, however, it has yet to be declared stable enough to be daily-driven, and it has no public instances.
Other than all this, a non-public development version of @silverpill's Mitra has nomadic identity via ActivityPub in development. I'm not sure whether FEP-ef61 is implemented in the release version yet. It's the only Fediverse project aiming to implement nomadic identity which Mike Macgirvin has nothing directly to do with.
The ultimate goal is to be able to clone a Fediverse identity across project borders. Only considering stable releases, it's currently only possible to clone Hubzilla channels within Hubzilla, using Zot6, or (streams) channels within (streams), using Nomad.
Unfortunately, Mike has officially retired from Fediverse development and only occasionally submits code to the streams repository and Forte anymore.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Mitra -
@glyn Decentralised identity has been available for longer than Mastodon, let alone ActivityPub. Only that it is known as "nomadic identity" here.
It was first implemented by Friendica creator @Mike Macgirvin ?️ in the Zot protocol in 2011 and in a Friendica fork named Red in 2012, later renamed into the Red Matrix, eventually reworked and renamed into Hubzilla in 2015.
Proof: This Hubzilla channel of mine actually simultaneously resides on two servers.
(Almost) everything that Mike has made afterwards, forks and forks of forks of Hubzilla, used to have or still have nomadic identity implemented.
His streams repository contains a fork of a fork... of Hubzilla that intentionally has no name, and that offers nomadic identity via the Nomad protocol with better compatibility with non-nomadic ActivityPub. In July, it had decentralised IDs as per FEP-ef61 (see also here) implemented, a first step by Mike to fully implement nomadic identity in ActivityPub.
Forte, Mike's most recent fork from August, had all support for Nomad and Zot6 removed and only uses ActivityPub anymore while still offering nomadic identity. To my best knowledge, however, it has yet to be declared stable enough to be daily-driven, and it has no public instances.
Other than all this, a non-public development version of @silverpill's Mitra has nomadic identity via ActivityPub in development. I'm not sure whether FEP-ef61 is implemented in the release version yet. It's the only Fediverse project aiming to implement nomadic identity which Mike Macgirvin has nothing directly to do with.
The ultimate goal is to be able to clone a Fediverse identity across project borders. Only considering stable releases, it's currently only possible to clone Hubzilla channels within Hubzilla, using Zot6, or (streams) channels within (streams), using Nomad.
Unfortunately, Mike has officially retired from Fediverse development and only occasionally submits code to the streams repository and Forte anymore.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Mitra -
@glyn Decentralised identity has been available for longer than Mastodon, let alone ActivityPub. Only that it is known as "nomadic identity" here.
It was first implemented by Friendica creator @Mike Macgirvin ?️ in the Zot protocol in 2011 and in a Friendica fork named Red in 2012, later renamed into the Red Matrix, eventually reworked and renamed into Hubzilla in 2015.
Proof: This Hubzilla channel of mine actually simultaneously resides on two servers.
(Almost) everything that Mike has made afterwards, forks and forks of forks of Hubzilla, used to have or still have nomadic identity implemented.
His streams repository contains a fork of a fork... of Hubzilla that intentionally has no name, and that offers nomadic identity via the Nomad protocol with better compatibility with non-nomadic ActivityPub. In July, it had decentralised IDs as per FEP-ef61 (see also here) implemented, a first step by Mike to fully implement nomadic identity in ActivityPub.
Forte, Mike's most recent fork from August, had all support for Nomad and Zot6 removed and only uses ActivityPub anymore while still offering nomadic identity. To my best knowledge, however, it has yet to be declared stable enough to be daily-driven, and it has no public instances.
Other than all this, a non-public development version of @silverpill's Mitra has nomadic identity via ActivityPub in development. I'm not sure whether FEP-ef61 is implemented in the release version yet. It's the only Fediverse project aiming to implement nomadic identity which Mike Macgirvin has nothing directly to do with.
The ultimate goal is to be able to clone a Fediverse identity across project borders. Only considering stable releases, it's currently only possible to clone Hubzilla channels within Hubzilla, using Zot6, or (streams) channels within (streams), using Nomad.
Unfortunately, Mike has officially retired from Fediverse development and only occasionally submits code to the streams repository and Forte anymore.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Mitra -
Proof generation and verification algorithms in
eddsa-jcs-2022cryptosuite are changing:https://socialhub.activitypub.rocks/t/fep-8b32-object-integrity-proofs/2725/73