#fedi #askfediIs the #ActivityPub protocol any closer to having data portability?

#fedi #askfedi
Is the #ActivityPub protocol any closer to having data portability?
And how about single ID usable in different apps?
And how about E2EE?

Thank you!

@patrickleavy you should follow @soatok re e2ee

@tmaher @soatok thank you! Can they point to some kind of roadmap for the protocol?

@Patrick Leavy

Is the #ActivityPub protocol any closer to having data portability?

Have you read about nomadic identity yet? (https://joinfediverse.wiki/Nomadic_identity)

There is only one Fediverse server application that offers full-blown server-side nomadic identity via ActivityPub, and that's Forte (https://codeberg.org/fortified/forte). This won't change anytime soon. For there is one critically important thing that has never happened yet, and that's the conversion of non-nomadic, account-equals-identity, ActivityPub-based Fediverse software to fully nomadic, identity-uncoupled-from-accounts, ActivityPub-based Fediverse software.

Forte itself came to exist in 2024 as a fork of something colloquially called (streams) which is already nomadic, but based on its own protocol named Nomad with ActivityPub as an optional secondary protocol. And (streams) is a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, the first nomadic Fediverse software, created in 2012 under the name Red and based on a precursor of Nomad.

A very long-term dream is a fully nomadic Fediverse. Not only would all Fediverse server software be every bit as nomadic as Hubzilla, but it'd be possible to move and even clone identities between different server applications. As it stands now, moving and cloning is only possible within Hubzilla, within (streams) and within Forte.

And how about single ID usable in different apps?

This would only be possible in an entirely nomadic Fediverse where you can clone your identity from anywhere to anywhere. And even then you'd have to first register a local account on whichever server you want to use and then clone your existing identity onto this account on this server.

Otherwise, this is not possible. And it isn't possible at all without registering a local account on whichever server you want to create.

I mean, I've read this request countless times.

• Create an account on mastodon.social.
• Go to peertube.tv.
• Log onto peertube.tv with your mastodon.social credentials. Right away. Without first creating an account on peertube.tv.
• Upload a video credited to patrickleavy@mastodon.social.

There are lots of reasons why this is technologically impossible.

First of all: Where would peertube.tv know your mastodon.social login credentials from? Your name and at least the salted hash of your passphrase?

Besides: Where would peertube.tv store your data?

On mastodon.social where your account is?

And, pray tell, where would mastodon.social store a video the same way as PeerTube stores it, all the way to PeerTube's trademark peer-to-peer load balancing? Also, how and why do you think should mastodon.social authorise peertube.tv to directly, remotely write to mastodon.social's local database and data storage?

On peertube.tv?

Well, that'd require peertube.tv to have a record of your identity in its local database. It can't store a video locally. and reference it locally through mastodon.social's local database. So peertube.tv's server backend would have to know you. It would have to have your identity.

Where would it get that?

Again, no, it can't just simply reference mastodon.social's database for that. It'd need that record in its own local database.

Do you really believe that peertube.tv could go and leech all your account credentials from mastodon.social and automagically store them locally? Do you really believe mastodon.social will let it do that?

And do you seriously believe that if free, open-source, amateur-developed server software can easily do that, proprietary, closed-source, professional, military-intelligence-grade (as in FBI, DHS, CIA, NSA, STRATFOR, MI5, MI6, Mossad, Shin Bet), ultra-high-end espionage and surveillance software like Palantir or NSO Pegasus has no way at all of doing that?

No, there's literally only one possible way for peertube.tv to get to know you and know whom this video belongs to if you upload one. And that's by you registering a local account on peertube.tv. Manually.

Okay, now you (or someone else) may come and say, "But Pixelfed can literally do that! I can log onto Pixelfed with my Mastodon account!"

No. No, you can't. Sorry to say, but you can't.

Pixelfed pretends you can. For the sake of convenience and ease-of-use. But it's bogus. All show. A smoke screen.

What Pixelfed actually does when you "log into it with your Mastodon account": It takes your Mastodon login name, it takes your Mastodon passphrase, and it registers a local account on that Pixelfed server with your Mastodon login credentials.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #PeerTube #Pixelfed #Hubzilla #Streams #(streams) #Forte #NomadicIdentity

@patrickleavy It's getting closer:

https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md

@silverpill oh wow, that seems to have it all! What would it take to get that adopted?

@patrickleavy It is already implemented in 3 projects, and the 4th is coming. Hopefully more developers will join in the future.

Advanced capabilities like re-usable identity and e2ee are currently in research phase.

@Patrick Leavy A whole lot. Sorry, but this will be very very very long again.

I don't know if you've read my previous (very long) commentary. But just implementing one or two FEPs won't get you the same full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) that Hubzilla (what I'm writing from right now; https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) has had since 2012. And having this level of nomadic identity has to be the goal.

What has to be done is:

Take something like Mastodon.
Non-nomadic.
Where your account, your login, equals your identity.

Make your identity cloneable

Now, before you can make identities nomadic, you have to uncouple them from the login, from the account.

Mastodon has to introduce a sort of container for your identity, like the channels that Hubzilla, (streams) and Forte have always had (https://joinfediverse.wiki/Channels_(Hubzilla_&_(streams))). This is necessary so that a future nomadic Mastodon will know what to clone and what not to clone. For example, cloning your password is dangerous nonsense.

So, everything that makes up your account except for your login credentials will have to be moved into this container.

• your short name
• your long name
• your profile images, including alt-texts
• your profile
• your followers
• your followed
• your toots, including stats like faves, boosts etc.
• copies of the conversation trees of all your toots, including stats like faves, boosts etc. as well as attached files for each message
• all files you've ever attached to toots
• your settings
• your filters
• your mutes
• your blocks
• your server blocks
• etc.

Essentially, everything except for your login credentials will have to be moved from directly residing on your account into that box.

Change your login

Also, your login will have to change from short name + passphrase to e-mail + passphrase. Your short name is part of your identity, it's in the container, it will be cloned, so it can't be used to log you in anymore.

In order for this to work, half of Mastodon's server backend will have to be rewritten.

Decentralised IDs

Next, Mastodon must switch from the Webfinger IDs that it uses now to decentralised IDs as per FEP-ef61. For a while, I guess, it will have to use both next to one another. Then it will have to phase out its Webfinger IDs.

The decentralised IDs must be tested against other Fediverse software that already understands them or that's nomadic itself: (streams), Forte, Mitra, Tootik. For example, @silverpill of Mitra and @Mike Macgirvin of (streams) and Forte must test whether their software correctly understands Mastodon's DIDs. And the Mastodon developers must test whether Mastodon correctly understands the DIDs from Fediverse server applications that already use them.

Once it has gotten rid of its Webfinger IDs, the next phase can start.

Implement cloning within Mastodon

The central element of nomadic identity is not the ability to move your identity. That's only a byproduct of cloning your identity.

A clone, in nomadic identity, is a full backup of the container with your identity in it. A real-time, live, bidirectional backup that you can log into and use just like the "original". The clone always has the same idea as the original, regardless of which server it's on.

The key elements of clones and cloning must be implemented and tested:

• cloning an identity container to a different server after registering a new, blank account there
• cloning an identity container to a different server where you already have an account with a different containerised identity
• anything that happens on the original being sync'd to the clone
• anything that happens on the clone being sync'd to the original
• clone going offline, things happening on the original, clone coming back online, things that happened on the original being reliably sync'd to the clone
• original going offline, clone still working with the ID based on the original's domain
• original going offline, things happening on the clone, original coming back online, things that happened on the clone being reliably sync'd to the original
• making additional clones of an identity container that has already been cloned at least once
• the whole syncing shebang from the original to any number of clones
• the whole syncing shebang from one of the clones to the original and also directly to the other clones
• declaring one of the clones the new original, thus changing the ID of both the former original and all clones

Implement moving within Mastodon

Only when cloning works reliably, we can talk about moving, even though that's what everyone on Mastodon is giddy about.

Why? Because moving involves cloning. It's an automated process. At least it is on Hubzilla, (streams) and Forte, and it really should be one on nomadic Mastodon.

Basically, first you make a clone.
Then you declare the clone the new original, and your old original is demoted to a clone.
Then you have to wait until your change of ID from changing the original has federated to all your followers and followed and everywhere and whatnot.
Then, one last sync so that both the former-clone-now-new-original and the old-original-now-clone are really identical, and you won't lose any data.
Then your old-original-now-clone is deleted. We don't want to leave any dead stuff behind, now, do we?
Lastly, if your old account where your old original used to reside has no other identity on it, the whole account is deleted. In nomadic containerised identity, accounts cannot/should not exist with no identity container on them.

Cloning and moving beyond Mastodon

The last possible step is still utter science-fiction: Cloning or moving from Mastodon to something else that's nomadic and understands FEP-ef61.

Cloning or moving from Mastodon to Mitra. From Mastodon to Tootik. From Mastodon to (streams). From Mastodon to Forte. Oh, and maybe also back to Mastodon.

The difficult part is not only to make Mastodon capable of cloning identity containers to other nomadic software. And to make Mastodon accept identity containers from other nomadic software being cloned to Mastodon. I mean, this would be difficult already. (streams) and Forte are vastly, vastly different from Mastodon.

No, the difficult part is to make these four capable of cloning from or to someplace else. As it stands now, you can only clone from Mitra to Mitra, from Tootik to Tootik, from (streams) to (streams), from Forte to Forte. Even cloning between (streams) and Forte has never been possible, even though they're very similar. Oh, and cloning from and to Hubzilla is another story because Hubzilla doesn't have FEP-ef61 implemented.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #Tootik #NomadicIdentity

@jupiter_rowland @patrickleavy We have a lot of work ahead.

@jupiter_rowland @silverpill we are thinking of building a federated version of Facebook Groups, so people can leave Meta's cesspit.

What you describe sounds ideal - minus the science fiction at the end (we'd only need cloning/moving within our app initially).

And since it is new software then all the Mastodon problems you describe do not apply. All these features could be baked in from the start. We would need E2EE within the groups (so the host is blind) - just for an added challenge

@jupiter_rowland thank you - great info. Actually that's what I thought would be happening with portable ID: just creating a new local account but reusing the same UN and PW.

I'm not sure what happens with Nostr or ATproto. But I see no reason to be too ambitious about it in the fediverse - it would be more of a convenience.

Our goal is to develop a federated communities app that has to features of Facebook Groups, except with E2EE within the groups, and a federated news feed outside them.

@Patrick Leavy You don't even have to build it. It already exists in the Fediverse. No need to reinvent the wheel.

Hubzilla, (streams) and forte offer you not only full nomadic identity, but also groups. Optionally private groups. That can optionally hide from Fediverse account/channel directories. Optionally with any number of moderators from anywhere on Friendica, Hubzilla, (streams) and Forte.

They have the most advanced permissions systems in the whole Fediverse.

They support enclosed threaded one-post-many-comments conversations with thread titles like on Facebook, like on Tumblr, like on any blog out there, like in any forum out there.

The character limit on Hubzilla is over 16 million; on (streams) and Forte, it's over 24 million. The number of options in polls is practically unlimited, as is the number of images that can be embedded in messages. And with "embedded," I mean like in a blog post or on a website with text above and below the images.

At the same time, they're part of the Fediverse. Hubzilla is based on Zot6/an older version of Nomad; ActivityPub can be activated. (streams) is based on Nomad; ActivityPub is optional, but activated by default. Forte is based on ActivityPub. Any Fediverse software that recognises groups recognises their groups as such.

Here is an article with a number of tables in which I've compared the features of Mastodon, Friendica, Hubzilla, (streams) and Forte:

https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392.

CC: @silverpill

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Forte #FacebookGroups #Groups #FediGroups #FediverseGroups

@patrickleavy
You might want to take a look at @HolosSocial which is working on some pretty incredible things. I've not used it personally (yet) but it keeps all of your data on your phone which acts as it's own instance and then communicates through relays. From what I've seen E2EE is already built in.

Not sure if it covers what you're looking for or not but it's worth looking over.

@Patrick Leavy Well, nomadic identity, as it is, does not use the same login credentials on all servers. That'd be a security risk.

For example, I have this Hubzilla channel here cloned across two Hubzilla hubs: hub.netzgemeinde.eu and hub.hubzilla.de.

A Hubzilla account requires an e-mail address and a password. It can be different on different hubs, and in fact, it should. I may or may not use different passwords on these two hubs.

But the account only serves as a login, as an access to the channel(s) hosted on them. It has nothing to do with my identity. Thus, it also does not know or use my short name.

Nonetheless, on these two independent accounts which may or may not have completely different login credentials, I have two instances of this Hubzilla channel here which are (or should be) constantly kept perfectly identical to one another. (In fact, I have another channel with a separate identity that's cloned across the same two hubs. Nomadic identity at Hubzilla/(streams)/Forte level comes with the side-effect that you can have what amounts to multiple separate Mastodon accounts, but all under the same login.)

So you can use the same e-mail address and the same password. But you don't have to. And, truth be told, you really shouldn't.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #NomadicIdentity

@bobkmertz @HolosSocial oh wow the signal protocol? Perfection!

I wonder if this design could be adapted for a Groups style app, with each group containing chats, events calendar and files - all E2EE? And then have a non-encrypted public news feed attached to each group?

What happens when the volume of content goes very high and your device (mobile) runs out of space?

@jupiter_rowland @silverpill
Steams looks interesting as a base. I think the only thing missing would be the E2EE.
What we're planning is something that would be used by any kind of community - a sports team, a band, an activist group, investigative journalists. They would have their own group, and everything within it would be private to them, but also there's a public newsfeed. E2EE so host is blind.
Logged in you'd see which groups you are properly 'in', and those you just follow for news.

@patrickleavy @jupiter_rowland What programming language do you plan to use?

@silverpill @jupiter_rowland not sure yet. The other founder of Rebel Tech Alliance (the technical one) would build everything using Elixir if you let him. I'm not a developer by trade do am not so particular.

@patrickleavy @jupiter_rowland If you decide to develop a new project from scratch, there are currently only two libraries implementing portable identity primitives: APx (Rust) and Fedify (JavaScript, work in progress). For end to end encrypted groups, several solutions are currently being explored. Most likely we will end up using MLS.

I am working on a solution that is compatible with portable identity: https://codeberg.org/silverpill/feps/src/branch/main/0806/fep-0806.md. It is intended to be used for direct messages but may be upgraded to groups later. I think other proposed solutions to E2EE are not compatible with portable identities.

@silverpill @jupiter_rowland thank you - this is very helpful.
Tagging the other RTA founder @brenetic

We've stalled this project for ages because we're waiting for the ideal protocols combo. So the conversation with you is really helpful!