#fep_ef61

2025-03-19

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 with did:key, but might be useful with other DID methods.
I am also considering moving gateways property to actor's endpoints mapping, where server-wide endpoints such as sharedInbox are usually defined (in our case they are "DID-wide").

#fep_ef61 #NomadicIdentity

2025-02-15

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

#fep_ef61

2025-01-09
@Ben Pate 🤘🏻 It isn't even really parts of Zot. It's all being (or already has been) cast into ActivityPub FEPs, so no need to look at Zot (which is named Nomad now, by the way).

Mostly, it's nomadic identity which @Mike Macgirvin 🖥️ and Mitra's developer @silverpill (the actual driving force behind this) have been implementing using only ActivityPub for quite a while now. A key element is FEP-ef61 Portable Objects.

And they're fairly successful. The development version of Mitra was the first Fediverse server app based on ActivityPub from the get-go that got support for nomadic identity implemented (which, to my understanding, means Mitra's dev branch itself is not nomadic yet). Mike's (streams) has support for nomadic identity via ActivityPub in its stable release already. And Mike's Forte, which is highly experimental and not officially released to the public yet, is the very first Fediverse project to actually feature nomadic identity using only ActivityPub. Mike has removed all traces of Nomad from it.

Still, there's a long way to go. ActivityPub-based nomadic identity itself is still experimental. And permissions in the style of Hubzilla, (streams) and Forte have yet to be defined in FEPs, but they'll be necessary to roll ActivityPub-based nomadic identity out.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mitra #Hubzilla #Streams #(streams) #Forte #NomadicIdentity #FEP_ef61
2024-12-11
@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
2024-12-06

Today, on the anniversary of publishing FEP-ef61, nomadic actors on Streams and Mitra made their first contact.

I created a signed Follow activity 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 an Accept activity back, which I then picked from my inbox on the gateway.

#fep_ef61 #NomadicIdentity

2024-12-06

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.

#fep_ef61 #NomadicIdentity #DataPortability

2024-11-28

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

2024-11-27

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 digestMultibase property to objects representing images and other external resources, and hashlinks are recommended for references (because they are also based on multihashes).

Adding digestMultibase is 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

2024-11-17

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)

#NomadicIdentity #fep_ef61

2024-11-04
@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
2024-10-22

did:dns might be a good choice for FEP-ae97 clients.
It supports key rotation, but a web service is not required, so people don't need to deploy anything to create an identity. Just generate a secret key in your client, add a resource record to your domain and start posting.

#fep_ef61 #fep_ae97

2024-10-19
@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
2024-10-18
@Clairement crevée @Juanro :croqueta: @Mastodon Engineering AFAIK, there are only three implementations of FEP-ef61. I'd call two of them barely not experimental anymore at best, and the third one, the only one that actually seems to rely on it because it places all bets on nomadic identity via ActivityPub, is not really open to the public yet.

FEP-ef61 itself seems to be finalised (don't take my word for it), but getting it to work is anything but easy (intentionally left the DID in the link). So it may be better to watch the other implementations for a while.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DecentralizedIdentity #FEP_ef61
2024-10-14

'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

#fep_ef61

2024-10-12
@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
2024-09-27

FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/397

I fixed proof.verificationMethod values in examples, as well as accompanying text. These values should include fragments that identify a specific key in a DID document, so they are not actually DIDs but DID URLs (a similar change was made in FEP-8b32).
I also added a paragraph on authentication and authorization (with a normative reference to FEP-c7d3), and described WebFinger address reverse discovery in compatibility mode.

#NomadicIdentity #fep_ef61

2024-09-18

I'm working on a Rust library for building ActivityPub apps:

https://codeberg.org/silverpill/mitra/src/branch/main/apx_sdk

This code was originally a part of Mitra, but over time I moved re-usable functions into independent packages and then started using them in other projects, Activity Connect and fep-ae97-client. Compared to activitypub-federation-rust, it is a low-level library with fewer dependencies, suitable for both servers and clients. The key feature is support for nomadic identity.

Currently there's no documentation and API is not well designed, but I will be improving it. The license is AGPL-3.0

#fedidev #fep_ef61

2024-08-26
@Mike McCue If you really want to push it to the limit, here are two suggestions.

@Mike Macgirvin 🖥️ has been a Fediverse developer for 14 years. He has created three Fediverse protocols, he has invented nomadic identity, he has created a whole bunch of Fediverse server applications from Mistpark, today known as Friendica, to Hubzilla to the streams repository to Forte most recently, all forked from each other. He currently maintains the latter two.

He's on (streams) himself, but his channel is still an "old school" one without FEP-ef61 implemented and without its DID scheme.

Also, there is @silverpill, the creator and maintainer of Mitra. Apart from (streams) and Forte, Mitra is the only other Fediverse project that's working on implementing FEP-ef61 and nomadic identity via ActivityPub. Of course, he's on Mitra himself. And unlike (streams), Mitra has switched existing actors to FEP-ef61 on recent versions.

This means that you can not only test Flipboard's compatibility with Mitra, but you can also test Flipboard's compatibility with FEP-ef61 and its DID scheme. Keep in mind, though, that it's still very much a work in progress, and it may change.

Unfortunately, I don't know any (streams) channels with a DID right off the bat that could be interesting for Flipboard. I have two myself, but they're uninteresting.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #FEP_ef61 #Mitra #Streams #(streams)
2024-08-24
@John Spurlock Rather unexpectedly, it even works with Hubzilla and (streams) channels, including (streams) channels on newer accounts with FEP-ef61 support.

It's just a pity that it absolutely has to run through Cloudflare.

#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #FEP_ef61 #CloudFlare
2024-08-23
@_jayrope @Flatbush Gardener 🌈 Okay, I've edited the post. For one, my ID was still in the URL, maybe that caused the issue. To be on the safe side, I've also removed the FEP-ef61 stuff that's of no use for you anyway.

#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #FEP_ef61

Client Info

Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst