Mathstodon

0 posts0 participants0 posts today

Feral Ferment@<a href="https://hachyderm.io/@hrefna" rel="nofollow noopener noreferrer" target="_blank">Hrefna (DHC)</a> <blockquote>If your server disappeared tomorrow with no ability to export your follower graph, how would you rebuild it? If you do a server move, what happens to your post history?</blockquote> Widespread adoption of Nomadic Identity, if it ever happens, may help with this. I am sure you already know this, but for other readers, these two 2017 articles explain how Nomadic Identity works in Hubzilla, which is based on the Nomad/Zot protocol. #^<a class="" href="https://medium.com/@tamanning/nomadic-identity-brought-to-you-by-hubzilla-67eadce13c3b" rel="nofollow noopener noreferrer" target="_blank">https://medium.com/@tamanning/nomadic-identity-brought-to-you-by-hubzilla-67eadce13c3b</a> #^<a class="" href="https://medium.com/@tamanning/getting-started-with-nomadic-identity-how-to-create-a-personal-channel-on-hubzilla-7d9666a428b" rel="nofollow noopener noreferrer" target="_blank">https://medium.com/@tamanning/getting-started-with-nomadic-identity-how-to-create-a-personal-channel-on-hubzilla-7d9666a428b</a> Mike Macgirvin recently got Nomadic Identity working on ActivityPub too. #^<a class="" href="https://fediversity.site/item/b69ce5a0-0c22-4933-8393-dce7100f4584" rel="nofollow noopener noreferrer" target="_blank">https://fediversity.site/item/b69ce5a0-0c22-4933-8393-dce7100f4584</a> Unfortunately, the ActivityPub world keeps pretending that Mike Macgirvin and his work does not exist (Nomadic Identity has been around and working in Hubzilla for roughly a decade). There's also OpenWebAuth (Federated Single Sign On). As Sean Tilley explains in this March 2024 article, Nomadic Identity and OpenWebAuth together can enable network resilience, censorship resistance, and ease of migration. #^<a class="" href="https://wedistribute.org/2024/03/activitypub-nomadic-identity/" rel="nofollow noopener noreferrer" target="_blank">https://wedistribute.org/2024/03/activitypub-nomadic-identity/</a> No idea whether Nomadic Identity, OpenWebAuth, conversation containers, etc. will ever get widespread adoption. At present, the user base of software such as Hubzilla, Forte etc. (which have these features) is negligible. And at least in case of Hubzilla (which I am using), the UI and UX needs a lot of work; don't know about Forte (which is based on ActivityPub). And yes, all the other problems with the Fediverse that you listed will still remain. At this point, I doubt if the Fedi will ever become socially and politically relevant. #<a class="" href="https://klacker.org/search?tag=ActivityPub" rel="nofollow noopener noreferrer" target="_blank">ActivityPub</a> #<a class="" href="https://klacker.org/search?tag=ATProto" rel="nofollow noopener noreferrer" target="_blank">ATProto</a> #<a class="" href="https://klacker.org/search?tag=Nomad" rel="nofollow noopener noreferrer" target="_blank">Nomad</a> #<a class="" href="https://klacker.org/search?tag=Zot" rel="nofollow noopener noreferrer" target="_blank">Zot</a> #<a class="" href="https://klacker.org/search?tag=NomadicIdentity" rel="nofollow noopener noreferrer" target="_blank">NomadicIdentity</a> #<a class="" href="https://klacker.org/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> #<a class="" href="https://klacker.org/search?tag=Fediverse" rel="nofollow noopener noreferrer" target="_blank">Fediverse</a>

Jupiter Rowland@<a href="https://io.waxandleather.com/@alisynthesis" rel="nofollow noopener noreferrer" target="_blank">Alison Wilder</a> Because if you want full-blown user rights and all the same features as a local user on all over 30,000 Fediverse instances, you need a local user account on each one of them. This means two things: <ul><li>If you come over to the Fediverse for the first time, and you register your first account on Mastodon, you automatically also register an account on 30,000+ more instances.</li><li>If you decide to host your own instance of whatever, and you spin it up for the first time, your instance immediately creates tens of millions of user accounts. One for everyone who has ever joined the Fediverse. Because anyone may decide to come over to your instance and use it, just like so.</li></ul> For one, this is utter overkill. Besides, this is technologically impossible. This would require all Fediverse instances to know all other Fediverse instances. With no exceptions. Like, if I start up my own (streams) instance for the first time, and half a second later, someone on the other side of the globe starts up a Gancio instance, they would immediately have to know each other. And all the other instances in the Fediverse. And, of course, it would require a newly-launched instance to know all Fediverse users. Again, with no exception. How and from which source are they supposed to know? That said, there is a single sign-on system for the Fediverse. It's called <a href="https://magicsignon.org/page/openwebauth/home" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a>. It was created by @<a class="" href="https://fediversity.site/channel/mikedev" rel="nofollow noopener noreferrer" target="_blank">Mike Macgirvin 🖥️</a> (creator of Friendica and all its descendants) in the late 2010s already for now-defunct <a href="https://joinfediverse.wiki/The_Zotlabs_projects#Zap" rel="nofollow noopener noreferrer" target="_blank">Zap</a>, a fork (of a fork?) of <a href="https://joinfediverse.wiki/Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> which, in turn, is a fork of the currently hyped Facebook alternative <a href="https://joinfediverse.wiki/Friendica" rel="nofollow noopener noreferrer" target="_blank">Friendica</a>. It was backported to Hubzilla in 2020. Everything that came after Zap, including the still existing <a href="https://joinfediverse.wiki/(streams)" rel="nofollow noopener noreferrer" target="_blank">streams repository</a>, got it, too. However, first of all, OpenWebAuth is only fully implemented on Hubzilla, (streams) and Forte. Plus, it has client-side support on Friendica. This means that Hubzilla, (streams) and Forte recognise logins on all four, but Friendica doesn't recognise logins from anywhere. As for Mastodon, OpenWebAuth implementation was actually developed to the point of an official merge request in Mastodon's GitHub repository. As far as I know, it was rejected. Mastodon won't implement OpenWebAuth, full stop. Besides, it doesn't give you all the same power as a local user. You can't log into Friendica, go to a Hubzilla hub and create a wiki or a webpage or a CalDAV calendar, just like so. OpenWebAuth is only for guest permissions. Because on Hubzilla, (streams) and Forte, permissions are everything. For example, let's assume you have an account and a channel on (streams). Let's also assume that your (streams) channel and this Hubzilla channel of mine here are connected. Furthermore, let's assume that I've decided to only allow my own full connections to see my profile. If you're logged out, and you go to my profile page, you see nothing. But then you log in. And you come back to my profile page (provided your browser is configured so that the Hubzilla hub that I call home is allowed to create cookies). My home hub recognises your login on (streams). It identifies you as you, as one of my contacts. Thus, it identifies you as someone who is permitted to see my profile. And all of a sudden, you see my profile. That, for example, is what OpenWebAuth is for. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Long" rel="nofollow noopener noreferrer" target="_blank">Long</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=LongPost" rel="nofollow noopener noreferrer" target="_blank">LongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLong" rel="nofollow noopener noreferrer" target="_blank">CWLong</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLongPost" rel="nofollow noopener noreferrer" target="_blank">CWLongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediMeta" rel="nofollow noopener noreferrer" target="_blank">FediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediverseMeta" rel="nofollow noopener noreferrer" target="_blank">FediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediverseMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener noreferrer" target="_blank">Fediverse</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener noreferrer" target="_blank">Friendica</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zap" rel="nofollow noopener noreferrer" target="_blank">Zap</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener noreferrer" target="_blank">Streams</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%28streams%29" rel="nofollow noopener noreferrer" target="_blank">(streams)</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Forte" rel="nofollow noopener noreferrer" target="_blank">Forte</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=SingleSignOn" rel="nofollow noopener noreferrer" target="_blank">SingleSignOn</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a>

Jupiter Rowland@<a href="https://mastodon.social/users/pfefferle" rel="nofollow noopener noreferrer" target="_blank">Matthias Pfefferle</a> Friendica has only got client-side support, i.e. Hubzilla, (streams) and Forte recognise Friendica logins, but Friendica doesn't recognise any logins. Also, the instance that you visit while logged in must accept cookies. And if you're using Firefox and containers, the instance that you're logged in on and the instance that you visit must be in the same container. But in general, this is technology from the late 2010s. Zap was declared stable with it in 2019. It was backported to Hubzilla in 2020, and it was immediately made available on everything that came after Zap. At least for me, it generally works like a charm. Both Hubzilla and (streams) instances recognise my Hubzilla login if all precautions are met. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Long" rel="nofollow noopener noreferrer" target="_blank">Long</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=LongPost" rel="nofollow noopener noreferrer" target="_blank">LongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLong" rel="nofollow noopener noreferrer" target="_blank">CWLong</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLongPost" rel="nofollow noopener noreferrer" target="_blank">CWLongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediMeta" rel="nofollow noopener noreferrer" target="_blank">FediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediverseMeta" rel="nofollow noopener noreferrer" target="_blank">FediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediverseMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener noreferrer" target="_blank">Friendica</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener noreferrer" target="_blank">Streams</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%28streams%29" rel="nofollow noopener noreferrer" target="_blank">(streams)</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Forte" rel="nofollow noopener noreferrer" target="_blank">Forte</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a>

Jupiter Rowland@<a href="https://caneandable.social/@DavidNason" rel="nofollow noopener noreferrer" target="_blank">David Nason</a> Pixelfed is wholly separate software from Mastodon on wholly separate servers with wholly separate owners. So yes, you need a separate Pixelfed account. It's a bit easier on Pixelfed if you're already on Mastodon: Pixelfed lets you automatically create a new user account by "logging in" with your Mastodon login credentials. But only Pixelfed has this as far as I know. Loops is wholly separate again, but there's only one instance so far because it's too unfinished to even be open-source. So you'll need a Loops account next to your Mastodon account and your Pixelfed account. Also, you'll have different followers on Mastodon, on Pixelfed and on Loops. But what you could do if you want your followers on Mastodon to see your Pixelfed posts is: Follow your own Pixelfed account from Mastodon. And then, whenever you post something interesting on Pixelfed, wait for it to arrive on your Mastodon timeline, and then boost it. @<a href="https://urbanists.social/@markstos" rel="nofollow noopener noreferrer" target="_blank">Mark Stosberg</a> There's one thing that exists already now: OpenWebAuth magic single sign-on. But it's only available on Hubzilla, (streams) and Forte and partially on Friendica. What it does is recognise your login on another instance, even on an instance of another server application. Hubzilla, (streams) and Forte recognise logins from Friendica, Hubzilla, (streams) and Forte, but Friendica can't recognise logins. However, this is only used by the permissions system. For example, someone whom I'm connected to could have made their profile only visible to a certain subset of their connections, including myself. If you visit their profile, you won't see anything. If I visit their profile, their home instance recognises my Hubzilla login, and I can see the profile. What it does not do is give you the same full-blown rights as a user with a local account. I can't just, like, go to some (streams) instance and post away as, what, jupiter_rowland@rumbly.net or go to a Hubzilla hub where I don't have an account and create a webpage or a wiki or a CalDAV calendar right away without logging in. That's not how it works. By the way, client-side OpenWebAuth support (= your login is recognised on Hubzilla, (streams) and Forte) was proposed and actually developed to the point of a pull request for Mastodon. As far as I know, it was rejected. OpenWebAuth won't come to Mastodon. CC: @<a href="https://social.coop/@foolishowl" rel="nofollow noopener noreferrer" target="_blank">FoolishOwl</a> @<a href="https://sociale.network/@oblomov" rel="nofollow noopener noreferrer" target="_blank">Oblomov</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Long" rel="nofollow noopener noreferrer" target="_blank">Long</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=LongPost" rel="nofollow noopener noreferrer" target="_blank">LongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLong" rel="nofollow noopener noreferrer" target="_blank">CWLong</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLongPost" rel="nofollow noopener noreferrer" target="_blank">CWLongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediMeta" rel="nofollow noopener noreferrer" target="_blank">FediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediverseMeta" rel="nofollow noopener noreferrer" target="_blank">FediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediverseMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener noreferrer" target="_blank">Fediverse</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener noreferrer" target="_blank">Mastodon</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Pixelfed" rel="nofollow noopener noreferrer" target="_blank">Pixelfed</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Loops" rel="nofollow noopener noreferrer" target="_blank">Loops</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener noreferrer" target="_blank">Friendica</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener noreferrer" target="_blank">Streams</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%28streams%29" rel="nofollow noopener noreferrer" target="_blank">(streams)</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Forte" rel="nofollow noopener noreferrer" target="_blank">Forte</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=SingleSignOn" rel="nofollow noopener noreferrer" target="_blank">SingleSignOn</a>

FenTigerAnyone interested in single sign-on / #<a class="" href="https://zotum.net/search?tag=SSO" rel="nofollow noopener noreferrer" target="_blank">SSO</a>? Want a new toy to play with? I've been experimenting with it recently, and now I've got something to share: an experimental demo of how a "Sign in with the Fediverse" mechanism might work. If you have a Mastodon or Hubzilla account, or an IndieAuth-style self-hosted identity, I'd like to invite you to try and sign in to my test site at <a class="" href="https://login.mythik.co.uk/" rel="nofollow noopener noreferrer" target="_blank">login.mythik.co.uk</a>. Headline features: <ul><li> User authentication/authorization based on the <a href="https://github.com/ory/" rel="nofollow noopener noreferrer" target="_blank">Ory</a> tools.</li><li> Supports signing in using an existing Fediverse (or other) account - or one you host yourself</li><li> Open source - well, not yet, but it could be, if people are interested in it</li><li> Written by a non-expert! Woefully insecure! All manner of attacks, just waiting to be found! Invite your security expert friends to the party, and laugh together at the n00b! Fun for all the family!</li></ul> Supported identity providers include: <ul><li> Mastodon (must be a recent version that includes <a href="https://github.com/mastodon/mastodon/pull/29191" rel="nofollow noopener noreferrer" target="_blank">this pull request</a>). <a href="https://mastodon.social/" rel="nofollow noopener noreferrer" target="_blank">mastodon.social</a> is known to work.</li><li> Hubzilla (any version). <a href="https://zotum.net/" rel="nofollow noopener noreferrer" target="_blank">zotum.net</a> is known to work.</li><li> <a href="https://indieweb.org/FedCM_for_IndieAuth" rel="nofollow noopener noreferrer" target="_blank">#</a><a class="" href="https://zotum.net/search?tag=IndieAuth" rel="nofollow noopener noreferrer" target="_blank">IndieAuth</a> / #<a class="" href="https://zotum.net/search?tag=FedCM" rel="nofollow noopener noreferrer" target="_blank">FedCM</a></li><li> Another instance of itself, using OpenID Connect</li></ul> (There's a chance Streams might work, too.) Protocols supported: <ul><li> <a href="https://openid.net/specs/openid-connect-discovery-1_0.html" rel="nofollow noopener noreferrer" target="_blank">#</a><a class="" href="https://zotum.net/search?tag=OIDC" rel="nofollow noopener noreferrer" target="_blank">OIDC</a> Discovery</li><li> <a href="https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document" rel="nofollow noopener noreferrer" target="_blank">Client ID Metadata Document</a></li><li> <a href="https://indieweb.org/FedCM_for_IndieAuth" rel="nofollow noopener noreferrer" target="_blank">FedCM for IndieAuth</a></li><li> <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md" rel="nofollow noopener noreferrer" target="_blank">#</a><a class="" href="https://zotum.net/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a></li><li> A method using the <a href="https://docs.joinmastodon.org/spec/oauth/" rel="nofollow noopener noreferrer" target="_blank">Mastodon</a> <a href="https://docs.joinmastodon.org/methods/accounts/#verify_credentials" rel="nofollow noopener noreferrer" target="_blank">API</a></li><li> <a href="https://indieauth.spec.indieweb.org/" rel="nofollow noopener noreferrer" target="_blank">Classic (non-FedCM) IndieAuth</a> (if you're lucky; I found this very hard to test, and had various problems with it)</li><li> My original experiments used <a href="https://openid.net/specs/openid-connect-registration-1_0.html" rel="nofollow noopener noreferrer" target="_blank">Dynamic Client Registration</a> but I've moved away from this.</li></ul> If you can get it to work - share a screenshot and let me know what you think! (I'll try to keep this running for a while, but I can't guarantee it - partly because I haven't finished trying to attack it yet. If I have to take it down for some reason, I'll edit this post to say so.)

Jupiter Rowland@<a href="https://social.coop/users/J12t" rel="nofollow noopener noreferrer" target="_blank">Johannes Ernst</a> <blockquote>same account for multiple instances</blockquote> This in its pure, nomadic form and with proven stability is only available on Hubzilla and (streams) anyway. They're also the only ones whose instances can detect off-site users' logins and grant them rights that other visitors don't have, provided said off-site users are on either of the two or Friendica. All thanks to OpenWebAuth. @<a class="" href="https://fediversity.site/channel/mikedev" rel="nofollow noopener noreferrer" target="_blank">Mike Macgirvin 🖥️</a>, creator of all three and maintainer of the streams repository, is currently working on implementing nomadic identity and (streams)' set of permissions using nothing but ActivityPub so it can become available to everything else in the Fediverse as well. <blockquote>share to fediverse</blockquote> I'm not quite sure, but I think @<a href="https://stefanbohacek.online/@stefan" rel="nofollow noopener noreferrer" target="_blank">Stefan Bohacek</a> or someone who commented on one of his posts has figured out how to share at least to Hubzilla. However, actual share buttons are all geared only towards Mastodon and hit-and-miss at best when it comes to anything else. The less something is like Mastodon, the less they work with it. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Long" rel="nofollow noopener noreferrer" target="_blank">Long</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=LongPost" rel="nofollow noopener noreferrer" target="_blank">LongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLong" rel="nofollow noopener noreferrer" target="_blank">CWLong</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLongPost" rel="nofollow noopener noreferrer" target="_blank">CWLongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediMeta" rel="nofollow noopener noreferrer" target="_blank">FediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediverseMeta" rel="nofollow noopener noreferrer" target="_blank">FediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediverseMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener noreferrer" target="_blank">NomadicIdentity</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener noreferrer" target="_blank">Friendica</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener noreferrer" target="_blank">Streams</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%28streams%29" rel="nofollow noopener noreferrer" target="_blank">(streams)</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ShareButton" rel="nofollow noopener noreferrer" target="_blank">ShareButton</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ShareButtons" rel="nofollow noopener noreferrer" target="_blank">ShareButtons</a>

Life is Tetris<a href="https://todon.eu/@jalcine" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@jalcine</a> Hi. Cold-calling to say your blog about domain name dependence [1] in <a href="https://qoto.org/tags/Indieweb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Indieweb</a> sounded like it was solved by <a href="https://qoto.org/tags/Hubzilla" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Hubzilla</a> / <a href="https://qoto.org/tags/Streams" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Streams</a>, and I was pleased to see it was already considered! [2]FWIW, they addresses the concerns about <a href="https://qoto.org/tags/OpenWebAuth" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#OpenWebAuth</a> in the Streams forum <a href="https://fediversity.site/channel/streams?mid=https://fediversity.site/item/aa7fc055-23ad-4c94-85b1-6e67bd39ba5b" rel="nofollow noopener noreferrer" target="_blank">https://fediversity.site/channel/streams?mid=https://fediversity.site/item/aa7fc055-23ad-4c94-85b1-6e67bd39ba5b</a>[1] <a href="https://jacky.wtf/essays/2024/question-domain-names/" rel="nofollow noopener noreferrer" target="_blank">https://jacky.wtf/essays/2024/question-domain-names/</a> [2] <a href="https://indieweb.org/OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">https://indieweb.org/OpenWebAuth</a>

AlexI just learned about <a href="https://social.tchncs.de/tags/nomadicIdentities" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#nomadicIdentities</a> and how <a href="https://social.tchncs.de/tags/openwebauth" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#openwebauth</a> can solve the biggest gripe I have with the <a href="https://social.tchncs.de/tags/fediverse" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#fediverse</a>: remote content I want to interact with. <a href="https://wedistribute.org/2024/03/activitypub-nomadic-identity/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://wedistribute.org/2024/03/activitypub-nomadic-identity/</a>

Ecologia Digital<a href="https://mato.social/tags/NomadicIdentity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#NomadicIdentity</a>: "<a href="https://mato.social/tags/OpenWebAuth" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#OpenWebAuth</a> used to be called <a href="https://mato.social/tags/MagicAuth" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MagicAuth</a>, because of how seamless the experience is...you can jump from one part of the <a href="https://mato.social/tags/Fediverse" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fediverse</a> to another, & your permissions will be granted automatically: your browser accesses a token inside of a cookie. That token references your <a href="https://mato.social/tags/DigitalIdentity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DigitalIdentity</a> in the Fediverse, verifies it, and a handshake is performed. Afterwards, anything you were given permission to access unlocks & becomes visible on the page." <a href="https://wedistribute.org/2024/03/activitypub-nomadic-identity/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://wedistribute.org/2024/03/activitypub-nomadic-identity/</a>

FenTigerA couple of days ago, the second iteration of my #<a class="" href="https://zotum.net/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> writeup was published as a draft #<a class="" href="https://zotum.net/search?tag=FEP" rel="nofollow noopener noreferrer" target="_blank">FEP</a>: #^<a class="" href="https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md" rel="nofollow noopener noreferrer" target="_blank">https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md</a> So now it's time to ask for feedback. Is it helpful? What's unclear? What's missing? What could be improved? @<a class="" href="https://fediversity.site/channel/mikedev" rel="nofollow noopener noreferrer" target="_blank">Mike Macgirvin 🖥️</a>, @<a class="" href="https://hub.somaton.com/channel/mario" rel="nofollow noopener noreferrer" target="_blank">Mario Vavti</a>, do you think you can find a bit of time to look at this? I'd hate to miss something important, and that's very easy with security related protocols. @<a class="" href="https://hz.eenoog.org/channel/pascal" rel="nofollow noopener noreferrer" target="_blank">Pascal (Hz)</a>, you've worked on OpenWebAuth too - does this match your understanding? I'm not going to do a lot more work on this right now but I'm certainly willing to collect feedback and update the draft.

0x1C3B00DAFEP-61cf: The OpenWebAuth ProtocolThis is the proposed FEP-61cf: The OpenWebAuth Protocol. OpenWebAuth is the “single sign-on” mechanism used by Hubzilla, (streams) and other related projects. It allows a browser-based user to log in to services across the Fediverse using a single identity. Once logged in, they can be recognised by other... <a href="https://mathstodon.xyz/tags/fediverse" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#fediverse</a> <a href="https://mathstodon.xyz/tags/fep" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#fep</a> <a href="https://mathstodon.xyz/tags/openwebauth" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#openwebauth</a><a href="https://socialhub.activitypub.rocks/t/fep-61cf-the-openwebauth-protocol/3907" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://socialhub.activitypub.rocks/t/fep-61cf-the-openwebauth-protocol/3907</a>

FenTigerFor a while now I've been meaning to take a look at #<a class="" href="https://zotum.net/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a>, but I've been a bit daunted by the reverse engineering effort that it would take. This changed when I came across this page:    #^<a class="" href="https://hz.eenoog.org/wiki/pascal/Fediverse(28)20(29)OpenWebAuth(28)20(29)support/Home" rel="nofollow noopener noreferrer" target="_blank">https://hz.eenoog.org/wiki/pascal/Fediverse(28)20(29)OpenWebAuth(28)20(29)support/Home</a> This links to three PRs adding OpenWebAuth to Mastodon and PixelFed. Reading these PRs saved me a lot of time by clearly highlighting the areas of the code which I needed to study. With these and a bit of grepping I've been able to implement most of #<a class="" href="https://zotum.net/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> locally, so that my toy instance can now log me into Hubzilla, and I can very nearly allow Hubzilla users to log in to me, too. Here's a quick writeup of how it works, in the "happy case". I'm wondering if it's worth polishing this further and making it into a #<a class="" href="https://zotum.net/search?tag=FEP" rel="nofollow noopener noreferrer" target="_blank">FEP</a>. 1. The OpenWebAuth flow can begin in one of two ways:   (a) The user visits the target instance and sees a login screen.  They type their Fediverse ID into a form field and click "Login".   (b) The user follows a link to the target instance. This link has a query parameter, <code>zid=</code>, which specifies the user's Fediverse ID. Either way, the target instance has learned the user's ID, but has not verified it yet. 2. The target instance constructs a URL of the form    <code>https://home-instance.example/magic?owa=1&bdest=<destination URL></code> The parts of this URL are:    Scheme: Must be HTTPS    Hostname: The same as the hostname portion of the user's ID    Path: Must be <code>/magic</code>    Query parameters:       <code>owa</code>: must be set to 1       <code>bdest</code>: The URL that the user is trying to visit. This is encoded as UTF-8 and then converted to a hexadecimal string. The user's browser is redirected to this URL. 3. The <code>/magic</code> endpoint at the user's home instance decodes the <code>bdest</code> destination URL. It performs a webfinger lookup on the root URL of the destination site and looks for a link with <code>rel</code> set to <code>http://purl.org/openwebauth/v1</code>. This identifies the target instance's <code>token</code> endpoint. The home instance constructs and issues a signed HTTPS request to this endpoint.  This request must have an <code>Authorization</code> header starting with the word <code>Signature</code> followed by the encoded HTTP signature. The <code>keyId</code> property of the signature points to the public key in the user's actor record, just as for ActivityPub signed requests. 4. The target instance's "<code>token</code>" endpoint extracts the "<code>keyId</code>", fetches the actor record, extracts the public key and verifies the signature. On success, it generates an URL-safe random string to use as a token.  This token is stored locally, associated with the actor who signed the message. The token is also encrypted using the actor's public key and the RSA PKCS #1 v1.5 encryption scheme. The encrypted result is encoded as URL-safe Base64 with no '=' padding bytes. Next it constructs the following JSON object in response: <pre><code>   {        "success": true,        "encrypted_token": <the base64-encoded token>    }</code></pre> On failure it can also return a result with <code>success</code> set to false. 5. The signed request issued by the <code>/magic</code> endpoint completes.  The home instance decodes the JSON response and verifies that <code>success</code> is true. Next it decodes the Base64-encoded encrypted token and decrypts it using the actor's private key. If successful, it takes the original <code>bdest</code> destination URL, adds the query parameter: <code>owt=<decrypted token></code>, and redirects the user's browser to it. 6. The user arrives at their destination URL. The target instance sees the <code>owt=</code> query parameter and checks its local storage for the token which it saved in step 4. If found, this token contains the user's verified identity, and the target instance logs them in, overriding any existing login they may have. The token is also deleted from local storage so that it cannot be redeemed more than once.

FenTigerWhat are the use cases for signed HTTP requests in the #<a class="" href="https://zotum.net/search?tag=Fediverse" rel="nofollow noopener noreferrer" target="_blank">Fediverse</a>? I'm aware of two: #<a class="" href="https://zotum.net/search?tag=ActivityPub" rel="nofollow noopener noreferrer" target="_blank">ActivityPub</a> (including public key lookups) and the #<a class="" href="https://zotum.net/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> <code>/owa</code> endpoint. Are they used for anything else? #<a class="" href="https://zotum.net/search?tag=FediDev" rel="nofollow noopener noreferrer" target="_blank">FediDev</a>

Jupiter Rowlandtl;dr: Hubzilla has had at least some of this for over a decade now. And it won't replace any of it with a new standard tailor-made for Mastodon. @<a href="https://mitra.social/users/silverpill" rel="nofollow noopener noreferrer" target="_blank">silverpill</a> If you look past projects based on ActivityPub and at projects that have ActivityPub as an additional protocol, some of this already exists. <blockquote>- Data portability. In my opinion, this is the most important problem. I'm in favor of <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md" rel="nofollow noopener noreferrer" target="_blank">FEP-ef61</a>, which also solves identity portability and unlocks many new features.</blockquote> Exists in the shape of nomadic identity. Invented by @<a class="" href="https://fediversity.site/channel/mikedev" rel="nofollow noopener noreferrer" target="_blank">Mike Macgirvin 🖥️</a> in 2011 with his Zot protocol and first deplayed in 2012 with the Red Matrix, nowadays known as <a href="https://joinfediverse.wiki/What_is_Hubzilla%3F" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a>. Also available on <a href="https://codeberg.org/streams/streams" rel="nofollow noopener noreferrer" target="_blank">(streams)</a>, Mike's current project at the end of a string of forks from Hubzilla, now based on the Nomad protocol. Mike would like to see nomadic identity and other special features of the Zot and Nomad protocols included in the ActivityPub protocol. He has actually submitted a number of proposals for this. They were all rejected. Even though he is a protocol developer first and foremost, and he has both created and worked on more Fediverse protocols than anyone else, so he should be considered competent. Nomadic identity with ActivityPub won't come unless either Evan Prodromou and the W3C commission cave in and allow Mike's suggestions, or someone re-invents the wheel from scratch in a way that's utterly incompatible to Hubzilla and (streams). And it won't come to Mastodon unless Eugen Rochko can imply that Mastodon has had it first. And there will never be a nomadic identity standard that meets Mike's requirements as well as Eugen's wishes. <blockquote>- End-to-end encryption. <a href="https://en.wikipedia.org/wiki/Messaging_Layer_Security" rel="nofollow noopener noreferrer" target="_blank">MLS</a> has become a standard, and it would be wise to adopt it. <a href="https://codeberg.org/fediverse/fediverse-ideas/issues/3" rel="nofollow noopener noreferrer" target="_blank">Issue 3 at fediverse-ideas</a> provides a good overview of what we have at the moment (not much). Some variation of <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md" rel="nofollow noopener noreferrer" target="_blank">FEP-ae97</a> is likely needed to make end-to-end encryption work.</blockquote> AFAIK, all three of Mike's still existing projects, <a href="https://joinfediverse.wiki/What_is_Friendica%3F" rel="nofollow noopener noreferrer" target="_blank">Friendica</a> from 2010, Hubzilla from 2012/2015 and (streams) from 2021, have it. Optionally, but still. I think Friendica actually advertises military-grade encryption. <blockquote>- Plugins. Something like <a href="https://docs.pleroma.social/backend/configuration/mrf/" rel="nofollow noopener noreferrer" target="_blank">Pleroma MRF</a>, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.</blockquote> Friendica, Hubzilla and (streams) have had support for add-ons, including third-party add-ons, plus a number of official add-ons since their respective inceptions. If you want a cross-platform add-on standard, I hope you don't expect these three to throw their own standards over board in favour of the new standard. Otherwise, good luck developing a replacement for Pubcrawl that makes Zot-based Hubzilla compatible with ActivityPub while working on ActivityPub-based Mastodon just the same. Friendica, Hubzilla and (streams) rely on add-ons for all federation beyond their respective base protocols (DFRN, Zot, Nomad). <blockquote>- Groups. We have several competing standards for groups: <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md" rel="nofollow noopener noreferrer" target="_blank">FEP-1b12</a>, <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/400e/fep-400e.md" rel="nofollow noopener noreferrer" target="_blank">FEP-400e</a>, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.</blockquote> Friendica, Hubzilla and (streams) have had support for discussion groups/forums since their respective inception. On Friendica, a group is a user account with special settings; on Hubzilla and (streams), it's a <a href="https://joinfediverse.wiki/What_are_channels_on_Hubzilla_and_(streams)%3F" rel="nofollow noopener noreferrer" target="_blank">channel</a> with special settings. In addition, especially Hubzilla and (streams) have access permission control on a level that most people for whom the Fediverse is only ActivityPub couldn't imagine in their wildest dreams. All three can be used by users from all over the Fediverse already now. Good luck forcing Friendica to give up its 13-year-old standard that's used by <a href="https://venera.social/profile/fediversenews" rel="nofollow noopener noreferrer" target="_blank">Fediverse News</a>, just to name one, and Hubzilla to give up its 11-year-old standard that blows everything else but what (streams) does out of the water. Good luck forcing them to adopt something inferior. On the other hand, good luck forcing <a href="https://joinfediverse.wiki/What_is_Lemmy%3F" rel="nofollow noopener noreferrer" target="_blank">Lemmy</a> and <a href="https://joinfediverse.wiki/What_is_Kbin%3F" rel="nofollow noopener noreferrer" target="_blank">/kbin</a> to switch to a wholly different standard. Don't forget that these two exist as well. And good luck having the Fediverse outside of Hubzilla and (streams) adopt both server-side and client-side OpenWebAuth. And I'm not even talking about how different Fediverse projects handle threads differently. Mastodon has a Twitter-like thread structure: many posts, tied together with mentiones. Just about everything that's built on ActivityPub has taken this over. Friendica, Hubzilla and (streams) have a Facebook/blog/Tumblr-like thread structure: one post, the start post, and many comments which aren't posts. It's similar on Lemmy and /kbin which are Reddit clones, only that they don't allow thread starters to moderate their own threads. <blockquote>- Quoting. <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/e232/fep-e232.md" rel="nofollow noopener noreferrer" target="_blank">FEP-e232</a> is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.</blockquote> This is something that almost the whole Fediverse has implemented, save for Mastodon. And again, Friendica has had quotes since its inception in 2010, almost six years before Mastodon was launched (which, by the way, federated with Friendica and Hubzilla on the spot). Hubzilla has had quotes since 2012, inherited from Friendica. Their way of quoting is dead-simple: BBcode. <code>[quote][/quote]</code> (streams) supports Markdown and HTML in addition to BBcode, but otherwise it's the same. Oh, and by the way: Friendica, Hubzilla and (streams) have also supported quote-posts a.k.a. quote-tweets a.k.a. quote-toots a.k.a. quote-boosts from their very beginnings. <blockquote>- Markets. So far there's only <a href="https://codeberg.org/silverpill/mitra" rel="nofollow noopener noreferrer" target="_blank">one</a> server implementation capable of processing payments.</blockquote> At least two. Hubzilla has a payment add-on, too. It isn't installed on all hubs, but it's there. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Long" rel="nofollow noopener noreferrer" target="_blank">Long</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=LongPost" rel="nofollow noopener noreferrer" target="_blank">LongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLong" rel="nofollow noopener noreferrer" target="_blank">CWLong</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLongPost" rel="nofollow noopener noreferrer" target="_blank">CWLongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediMeta" rel="nofollow noopener noreferrer" target="_blank">FediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediverseMeta" rel="nofollow noopener noreferrer" target="_blank">FediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediverseMeta" rel="nofollow noopener noreferrer" target="_blank">CWFediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFedisplaining" rel="nofollow noopener noreferrer" target="_blank">CWFedisplaining</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener noreferrer" target="_blank">Fediverse</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener noreferrer" target="_blank">Mastodon</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=MastodonIsNotTheFediverse" rel="nofollow noopener noreferrer" target="_blank">MastodonIsNotTheFediverse</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NotOnlyMastodon" rel="nofollow noopener noreferrer" target="_blank">NotOnlyMastodon</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ActivityPub" rel="nofollow noopener noreferrer" target="_blank">ActivityPub</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener noreferrer" target="_blank">Friendica</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=DFRN" rel="nofollow noopener noreferrer" target="_blank">DFRN</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot" rel="nofollow noopener noreferrer" target="_blank">Zot</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener noreferrer" target="_blank">Streams</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%28streams%29" rel="nofollow noopener noreferrer" target="_blank">(streams)</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Nomad" rel="nofollow noopener noreferrer" target="_blank">Nomad</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Lemmy" rel="nofollow noopener noreferrer" target="_blank">Lemmy</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=kbin" rel="nofollow noopener noreferrer" target="_blank">kbin</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%2Fkbin" rel="nofollow noopener noreferrer" target="_blank">/kbin</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener noreferrer" target="_blank">NomadicIdentity</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Group" rel="nofollow noopener noreferrer" target="_blank">Group</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Groups" rel="nofollow noopener noreferrer" target="_blank">Groups</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Forum" rel="nofollow noopener noreferrer" target="_blank">Forum</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Forums" rel="nofollow noopener noreferrer" target="_blank">Forums</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Quote" rel="nofollow noopener noreferrer" target="_blank">Quote</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Quotes" rel="nofollow noopener noreferrer" target="_blank">Quotes</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Encryption" rel="nofollow noopener noreferrer" target="_blank">Encryption</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=E2EE" rel="nofollow noopener noreferrer" target="_blank">E2EE</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=E2EEncryption" rel="nofollow noopener noreferrer" target="_blank">E2EEncryption</a>

Jupiter Rowland@<a href="https://hachyderm.io/@maegul" rel="nofollow noopener noreferrer" target="_blank">maegul</a> @<a href="https://social.coop/users/J12t" rel="nofollow noopener noreferrer" target="_blank">Johannes Ernst</a> To be fair, something like "mobile identity" already exists. In the Fediverse. Not as an experimental proof-of-concept, but in stable daily use for longer than Mastodon has even been around. It's called "nomadic identity". It was created by @<a class="" href="https://fediversity.site/channel/mikedev" rel="nofollow noopener noreferrer" target="_blank">Mike Macgirvin 🖥️</a> in 2011 with his Zot protocol and first implemented by himself in 2012 in the Red Matrix which became <a href="https://joinfediverse.wiki/What_is_Hubzilla%3F" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> in 2015. It's also part of the Nomad protocol, a successor of Zot, upon which Mike's latest creations commonly referred to as <a href="https://codeberg.org/streams/streams" rel="nofollow noopener noreferrer" target="_blank">(streams)</a> is based. Nomadic identity allows you to have your channel (similar to what an account is just about everywhere else) on multiple server instances at the same time. Not backup-like static copies, but identical clones which are being kept in sync in near-real-time. In case any of you don't know yet: Both can use ActivityPub as well, and they're federated with Mastodon. I'm actually writing this from a Hubzilla channel that has one spare clone. Also, both Hubzilla and (streams) have bidirectional support for another creation of Mike's, a single-sign-on system named OpenWebAuth which automatically recognises your login on compatible instances. The obvious catch is that neither of these features are available anywhere else, at least not to this extent. Hubzilla and (streams) are the only nomadic federated server applications, and they're also the only ones that with server-side OpenWebAuth support which means that they can recognise OpenWebAuth logins from elsewhere. And it's safe to say that what doesn't exist on Mastodon may be seen as non-existent in the Fediverse altogether. CC: @<a href="https://mastodon.social/@benpate" rel="nofollow noopener noreferrer" target="_blank">Ben Pate 🤘</a> @<a href="https://indieweb.social/@laurenshof" rel="nofollow noopener noreferrer" target="_blank">Laurens Hof</a> @<a href="https://jawns.club/@vicki" rel="nofollow noopener noreferrer" target="_blank">Vicki Boykis</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Long" rel="nofollow noopener noreferrer" target="_blank">Long</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=LongPost" rel="nofollow noopener noreferrer" target="_blank">LongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLong" rel="nofollow noopener noreferrer" target="_blank">CWLong</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLongPost" rel="nofollow noopener noreferrer" target="_blank">CWLongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener noreferrer" target="_blank">Fediverse</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener noreferrer" target="_blank">NomadicIdentity</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener noreferrer" target="_blank">Streams</a>

Jupiter Rowland@<a href="https://chaos.social/@kubikpixel" rel="nofollow noopener noreferrer" target="_blank">KubikPixel™</a> Kommt ganz drauf an, was man will. Die beste direkte Alternative dürfte #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Firefish" rel="nofollow noopener noreferrer" target="_blank">Firefish</a> ex #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CalcKey" rel="nofollow noopener noreferrer" target="_blank">CalcKey</a> sein, das #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener noreferrer" target="_blank">Mastodon</a> in Features weit voraus ist. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Volltextsuche" rel="nofollow noopener noreferrer" target="_blank">Volltextsuche</a> hat Mastodon gerade erst eingeführt, so daß die mangels brauchbarer Indizes noch gar nicht richtig nutzbar ist. Firefish hatte sie schon immer, weil auch #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Misskey" rel="nofollow noopener noreferrer" target="_blank">Misskey</a> sie schon immer hatte. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Textformatierungen" rel="nofollow noopener noreferrer" target="_blank">Textformatierungen</a> und #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zitate" rel="nofollow noopener noreferrer" target="_blank">Zitate</a> konnten Firefish und Misskey meines Wissens auch schon immer. Mastodon kann beides nur anzeigen, während Firefish sogar Textformatierungen erzeugen kann, die Mastodon nicht anzeigen kann. Oder Zeichenlimits beim Schreiben von Posts. Mastodon kann nur 500 Zeichen. Für mehr muß der Admin so tief in die Software einsteigen, daß man fast schon von einem Fork reden könnte. Firefish kann standardmäßig 3000 Zeichen, was der Admin meines Wissens auf der Oberfläche einstellen, also noch erhöhen kann. Zugegeben, beide hacken #<a class="" href="https://hub.netzgemeinde.eu/search?tag=AltText" rel="nofollow noopener noreferrer" target="_blank">AltText</a> rigoros bei 1500 Zeichen ab. Last but not least unterstützt Firefish meines Wissens die Mastodon-API, sollte also gute Unterstützung durch Mastodon-Apps haben bis darauf, daß man mit Apps, die nur für Mastodon entwickelt werden, auch fast nur das machen kann, was Mastodon kann. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener noreferrer" target="_blank">Friendica</a> ist natürlich noch mächtiger. Es hat Zeichenlimits in den Zigtausenden, es unterstützt wohl noch mehr Formatierungen, es hat einen Filehoster eingebaut, es hat einen öffentlichen Kalender eingebaut, man kann Konten als moderierte Gruppen/Foren einrichten usw. Und es hat mit all dem schon Erfahrungein seit 2010. Der Hauptnachteil dürfte aber sein, daß es weiter von Mastodon entfernt ist als Firefish. Es gibt mehr, was anders ist und anders läuft. Was man auf Mastodon gelernt oder von Twitter mitgenommen hat, kann man auf Friendica eigentlich gleich wieder vergessen. Posts schreibt man nicht wie Tweets, sondern wie Blogposts. Bilder werden nicht als Dateien angehängt, sondern woanders hochgeladen (meistens im eingebauten Dateispeicher) und irgendwo im Text eingebettet. Alt-Text ist kein separates Feld, sondern muß per Hand in den BBcode eingeflochten werden. Ein Content-Warning-Feld gibt's nicht, aber eins für den Titel und eins für die Zusammenfassung, wobei sich letzteres dann als dasselbe wie Content Warnings auf Mastodon entpuppt. Direktnachrichten gehen nicht mit @ und Rechteeinstellen, sondern mit !. Antworten sind nicht auch Posts, sondern Kommentare, und das ist ganz was anderes als ein Post. Und so weiter. Klar, Friendica kann mehr und einiges auch besser, aber Mastodon-Umsteiger müssen im Prinzip alles ganz neu lernen. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener noreferrer" target="_blank">Streams</a> von 2021 ist in Teilen noch mächtiger als Friendica (wobei ein Teil von Friendicas Features wieder fehlt), #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> von 2015 ist durchweg noch sehr viel mächtiger. Aber hier ist die Umgewöhnung noch heftiger, alleine schon, weil die eigene Identität nicht durchs Konto definiert ist, sondern in einem Kanal "containerisiert". Und man kann auf demselben Konto mehrere Kanäle mit separaten Identitäten haben. Und dann kommt noch #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadischeIdentit%C3%A4t" rel="nofollow noopener noreferrer" target="_blank">NomadischeIdentität</a> oben drauf, auch wenn die eigentlich der feuchte Traum vieler Mastodon-Nutzer ist. Sie erfordert nur eben Um-die-Ecke-Denken. Hubzilla ist natürlich so ziemlich der ultimative Alleskönner. Es ist mehr als nur Friendica mit ein bißchen Extrazeugs, wobei vieles genauso funktioniert wie auf Friendica und somit ganz anders als auf Mastodon. Hubzilla ist ein "Social CMS", das einem neben Social Networking und Gar-nicht-so-Microblogging auch voll formatiertes Macroblogging bietet, das sich in der Funktion kaum vom Gar-nicht-so-Microblogging unterscheidet, außerdem einfache Websites, Wikis, Cloudspeicher mit WebDAV, CalDAV und CardDAV und so weiter und so fort. Oben drauf gibt's ein sehr detailliertes Rechtemanagement, das auch eng verzahnt ist mit #<a class="" href="https://hub.netzgemeinde.eu/search?tag=SingleSignOn" rel="nofollow noopener noreferrer" target="_blank">SingleSignOn</a> durch #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a>. Aber auf der einen Seite steht dieser gigantische Funktionsberg, und auf der anderen Seite steht die Benutzeroberfläche. An sich könnte die extrem flexibel sein, sie unterstützt Komplett-Themes, die für jeden Kanal individuell wählbar wären. In der Praxis gibt es aber nur noch ein Theme, das gepflegt wird. Das ist noch von 2012, wurde aus einem Friendica-Standardthema für die #<a class="" href="https://hub.netzgemeinde.eu/search?tag=RedMatrix" rel="nofollow noopener noreferrer" target="_blank">RedMatrix</a> umgebaut, hat sich seitdem kaum bis gar nicht verändert und hat mit Usability kaum etwas zu tun. Alternativen sind in der Mache, aber noch nicht offiziell verfügbar. Dazu kommt die Dokumentation. Die wurde geschrieben von Entwicklern, die nicht wußten, wie man Nichtentwicklern etwas erklärt, also z. B. ganz normalen Endnutzern, und liest sich streckenweise eher wie ein technisches Lastenhaft. Noch dazu ist sie zu erheblichen Teilen so hoffnungslos veraltet, daß sie überhaupt nicht nutzbar ist. Ach ja: Textformatierung gibt's. Textformatierung mit Klickibunti und Echtzeit-WYSIWYG gibt's nicht. Wer keinen BBcode kann, hat verloren, weil einem auch die Buttons nur BBcode in den Editor packen. Auch wenn zum Glück zumindest die BBcode-Implementation von Hubzilla ziemlich gut dokumentiert und halbwegs aktuell ist. (streams) hat nicht mehr den Funktionsumfang von Hubzilla. Das Ziel ist hier eigentlich nicht, von vornherein einen Alleskönner zu haben, sondern eine Codebasis, um daraus was feines Eigenes zu bauen. Die Oberfläche sieht ganz ähnlich aus, ist aber einen Tick zugänglicher, vielleicht auch deshalb, weil es vieles einfach nicht mehr gibt. Erleichternd dürfte für einige dazukommen, daß auf (streams) alles wahlweise mit BBcode, Markdown oder HTML formatiert werden kann, so daß man keinen BBcode lernen muß, wenn man schon Markdown kann. (streams) hat auch eine bessere Anbindung von #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ActivityPub" rel="nofollow noopener noreferrer" target="_blank">ActivityPub</a> und Verbesserungen in der nomadischen Identität. Dafür kann es sich mit nichts anderem mehr verbinden, außer daß es immer noch RSS-Feeds erzeugt und E-Mail-Benachrichtigungen verschicken kann. Näher an Mastodon ist es damit aber nicht. Im Gegenteil: Verwirrend ist schon mal, daß es sich nicht um ein in sich geschlossenes Projekt mit Namen und Marke handelt. Es ist gar kein Projekt, sondern nur ein Code-Repository. Es hat auch keinen Namen und kein Logo. Es ist wirklich mit voller Absicht namenlos. Der Name "Streams" und das Wellenlogo gehören beide zum Repository, nicht zur Software. Daher auch die Klammern um den "Namen". Das heißt auch, daß die einzelnen Instanzen keine einheitliche Projektidentität haben. Mastodon-Instanzen identifizieren sich alle als Mastodon. Hubzilla-Instanzen identifizieren sich alle als Hubzilla. (streams)-Instanzen identifizieren sich als irgendwas, weil man da selbst etwas eintragen kann und muß. Waitman Gobbles öffentliche Instanz namens Rumbly identifiziert sich beispielsweise nicht als "Streams", sondern als "-get". Folge: Es ist nicht möglich, (streams)-Instanzen automatisiert zu crawlen, zu identifizieren und aufzulisten. Das wird noch zusätzlich dazu erschwert, daß mit ebenso voller Absicht die Statistikausgabe aus (streams) komplett entfernt wurde. Die einschlägigen Projekt- und Instanz-Listenseiten fürs #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener noreferrer" target="_blank">Fediverse</a> listen allesamt keine (streams)-Instanzen, und das werden sie auch nicht, weil das zum einen nicht gewollt und zum anderen wegen der uneinheitlichen Identifikation der Instanzen gar nicht möglich ist. Folge: (streams)-Instanzen zu finden, ist <a href="https://hub.netzgemeinde.eu/item/7961d936-9ccd-45f0-b635-7cf512b02324" rel="nofollow noopener noreferrer" target="_blank">Detektivarbeit</a>. Das dürfte auch erklären, warum es bei (streams) einen noch höheren Anteil an persönlichen Instanzen gibt, zumal es kaum öffentliche Instanzen mit offener Registrierung gibt. Ein gemeinsamer Nachteil von Hubzilla und (streams) ist: Smartphone-Apps kann man vergessen. Für Hubzilla gibt's eine, die seit 2018 nicht mehr gepflegt wird, also mehr als die Hälfte der Zeit, die es Hubzilla gibt. Die funktioniert inzwischen gar nicht mehr. Und auch die hat den Fokus nur aufs Mikroblogging gelegt. (streams) wird wohl nie eine Smartphone-App haben, eben weil es kein in sich geschlossenes Projekt mit fixer Projektidentität ist. Beide unterstützen nicht die Mastodon-API, soweit ich weiß. Also ist man so oder so auf den Webbrowser angeweisen. Andererseits sind beide Projekte so mächtig, daß es kaum möglich sein dürfte, ihren jeweils kompletten Funktionsumfang in eine dann immer noch leicht bedienbare Smartphone-App zu pressen.

bob<a href="https://wikis.world/@magnusmanske" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@magnusmanske</a> That's called <a href="https://diaspodon.fr/tags/openWebAuth" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#openWebAuth</a>, and it's implemented in the <a href="https://diaspodon.fr/tags/zot" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#zot</a> world (for instance with <a href="https://diaspodon.fr/tags/hubzilla" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#hubzilla</a>)

Jupiter Rowland@<a href="https://toots.nu/@jens" rel="nofollow noopener noreferrer" target="_blank">Jens Ljungkvist :mastodon:</a> @<a href="https://calckey.social/@box464" rel="nofollow noopener noreferrer" target="_blank">Jeff Sikes</a> @<a href="https://calckey.social/@kainoa" rel="nofollow noopener noreferrer" target="_blank">Kainoa</a> @<a href="https://calckey.social/@atomicpoet" rel="nofollow noopener noreferrer" target="_blank">Chris Trottier</a> Something similar to "one account on all projects" is already in the works. By and by, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener noreferrer" target="_blank">Fediverse</a> projects may adopt #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a>, a #<a class="" href="https://hub.netzgemeinde.eu/search?tag=SingleSignOn" rel="nofollow noopener noreferrer" target="_blank">SingleSignOn</a> implementation developed by @<a class="" href="https://macgirvin.com/channel/mike" rel="nofollow noopener noreferrer" target="_blank">mike</a> for #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> and currently implemented on Hubzilla, its direct predecessor #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener noreferrer" target="_blank">Friendica</a> and its latest not-quite direct descendant, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener noreferrer" target="_blank">Streams</a>. An implementation is also in development on #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener noreferrer" target="_blank">Mastodon</a>. It should not be confused with #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OAuth" rel="nofollow noopener noreferrer" target="_blank">OAuth</a> and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OAuth2" rel="nofollow noopener noreferrer" target="_blank">OAuth2</a>, these are something entirely different. What OpenWebAuth is that it recognises logins elsewhere. When I'm logged into this Hubzilla account, and I visit another Hubzilla hub or maybe a Friendica node or a (streams) instance, it will automatically recognise me. And it will grant me some extra "guest permissions" like being able to post directly on the wall of another Hubzilla or (streams) channel. What it does not do, however, is give me all the power on any Friendica node, Hubzilla hub or (streams) instance that a logged-in user with a user account has. I can't go to another Hubzilla hub and create a clone of my channel or create a brand-new channel or post an article or start a wiki or upload files just with my OpenWebAuth login credentials. And when Mastodon introduces OpenWebAuth, I still won't be able to go to any one random Mastodon instance and start tooting. All this would still require a local user account on that one specific instance. One account for the whole Fediverse is utopic. It's technologically impossible or just very very very unfeasible. The Fediverse has 24,000+ instances of dozens of projects. If you want full local user power everywhere in the Fediverse, you'll need one registered account on each one of these 24,000+ instances. Whenever someone joins mastodon.social, then RATATATATATATATATATATA, 24,000+ more accounts with the same login credentials will have to be created automatically. Also, the Fediverse has 12,000,000+ users. If you want full local user power everywhere in the Fediverse, then everyone else must have it, too. So every single instance of each Fediverse project will have to have one account per Fediverse user. The only exceptions would be those very few projects which are designed for only one user account. However, personal instances of projects that are designed for multiple user accounts will all be affected. The hapless Mastodon user who comes over to your personal Hubzilla hub to act like a registered user will neither know nor care if that hub is running on a root server in a data centre with two 36-core Xeon CPUs and enough RAM to make a 3-D CAD workstation cry or on a Raspberry Pi at your home. Now, let's assume someone has set up a new Web server with some Fediverse project installed on it. It doesn't matter if that's Mastodon or #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CalcKey" rel="nofollow noopener noreferrer" target="_blank">CalcKey</a> or #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Lemmy" rel="nofollow noopener noreferrer" target="_blank">Lemmy</a> or #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mitra" rel="nofollow noopener noreferrer" target="_blank">Mitra</a> or (streams) or whatever as long as it has #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ActivityPub" rel="nofollow noopener noreferrer" target="_blank">ActivityPub</a>. They start that thing up for the first time: <code>sudo systemctl start nginx</code> or so. And RATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA, that poor thing will sit for WEEKS registering over twelve million user accounts. Why? Because anyone in the Fediverse might come over anytime soon and want to use just this one specific instance as if they had registered their personal user account there. In order to be able to do that, they need a user account. By the way, not even the notorious featherweight #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Pleroma" rel="nofollow noopener noreferrer" target="_blank">Pleroma</a> could handle 12,000,000+ user accounts on one instance. Mastodon can do that even less, not to mention the heavyweight Friendica or the super-heavyweight Hubzilla. Speaking of Hubzilla, maybe a new Hubzilla hub might get away more easily when starting up for the first time. On Hubzilla, ActivityPub is optional per hub and then per channel. The hub admin can switch it on and off, and if it's on, the users can switch it on and off again for each one of their channels. So if ActivityPub is off on the admin side by default, new Hubzilla hubs will only register one user account for each Hubzilla and (streams) user out there, maybe also for the users on the few remaining instances of the #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zotlabs" rel="nofollow noopener noreferrer" target="_blank">Zotlabs</a> projects that went EOL on New Year's Eve 2022, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Redmatrix" rel="nofollow noopener noreferrer" target="_blank">Redmatrix</a>, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Osada" rel="nofollow noopener noreferrer" target="_blank">Osada</a>, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zap" rel="nofollow noopener noreferrer" target="_blank">Zap</a>, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Misty" rel="nofollow noopener noreferrer" target="_blank">Misty</a> a.k.a. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mistpark2020" rel="nofollow noopener noreferrer" target="_blank">Mistpark2020</a> and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Roadhouse" rel="nofollow noopener noreferrer" target="_blank">Roadhouse</a>. They all speak one native language, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot" rel="nofollow noopener noreferrer" target="_blank">Zot</a>. But once the admin activates the Pubcrawl app for their hub, that hub will immediately start registering user accounts for every user on every instance of every project that connects to Hubzilla via ActivityPub, each account with one channel with Pubcrawl on. And it will spend weeks or months doing so and not have any server resources left to do anything else in the meantime. Speaking of Hubzilla, there's also #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener noreferrer" target="_blank">NomadicIdentity</a>, the killer feature of the Zot protocol. Hubzilla has it, (streams) has it, and the (un)dead Zotlabs projects have it. Ideally, each Fediverse user would not get one account on each Hubzilla hub and each (streams) instance with one separate, unique channel on it. They would first get the accounts. On one account on one Hubzilla hub, one channel would be created. This channel would then be cloned across all Hubzilla hubs and to (streams). Advantage: Each Fediverse user would only have one channel for Hubzilla and (streams) together. They would have the exact same content on all Hubzilla hubs and, minus what Hubzilla can do that (streams) can't, all (streams) instances. Obvious disadvantage: Whenever someone decides to do something on that channel, it would have to be synced to all its clones in near-real-time, causing a lot of network traffic. And if you set up a new Hubzilla hub or (streams) instance, the creation of 12,000,000+ accounts would actually become a lesser problem. The bigger problem would be the 12,000,000+ channels that will be cloned onto your machine with everything on them. You'd better attach a few petabytes worth of HDD capacities to your personal little Raspberry Pi. By the way, if everyone had full local user rights on each Fediverse instance, the Fediverse would have over 300 billion local accounts.

Jupiter Rowland@<a href="https://hachyderm.io/@0xSim" rel="nofollow noopener noreferrer" target="_blank">Sim :blobfoxcomputer: :ferris:</a> At least I've seen Mastodon users demanding that everyone who is not on Mastodon make their posts so that nothing about them disturbs Mastodon users. This means no actual quotes because Mastodon doesn't know quotes. This means no bullet-point lists because Mastodon doesn't know bullet-point lists. This means not more than four images because Mastodon has to convert images from certain projects to file attachments and attach them behind the end of the post, and Mastodon can't attach more than four files to one post. In fact, this means only one picture because Mastodon seems to order file attachments and pictures the wrong way. And this means no sensitive pictures at all because Mastodon can't hide them behind a CW when they come in from outside of Mastodon. Oh, and it means posts no longer than 500 characters. As for your other paragraph, there are two possible solutions for this. One is halfway realistic. The realistic one means to introduce #<a class="" href="https://hub.netzgemeinde.eu/search?tag=SingleSignOn" rel="nofollow noopener noreferrer" target="_blank">SingleSignOn</a> in the shape of #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> (also invented by @<a class="" href="https://macgirvin.com/channel/mike" rel="nofollow noopener noreferrer" target="_blank">mike</a>) to Mastodon, Lemmy and /kbin. Then Lemmy and /kbin would recognise your Mastodon login. Also, this would require modifications to the Web UI for "guest users" as which you would count. Then you could do the same you can do now remotely from Mastodon, but on the Web UI of whatever Lemmy or /kbin instance you're currently on. But you would not have all features that users with a user account on that instance have, i.e. you can neither create nor moderate Lemmy communities or /kbin magazines. If you wanted these, too, this would require the second, impossible solution, namely the automatic creation of one user account for each Fediverse user on each Lemmy instance and each /kbin instance. This could be combined with OpenWebAuth, too, and automatically log you into your account on that respective instance. But whenever someone starts up a new instance, it would have to a) know all 12,000,000++ Fediverse accounts and b) immediately create one local account for each one of them.

Jupiter Rowland@<a class="" href="https://mastodon.social/@bobwyman" rel="nofollow noopener noreferrer" target="_blank">Bob Wyman</a> For starters, everything I've listed is not only part of the #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener noreferrer" target="_blank">Fediverse</a>, but bi-directionally federated with #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener noreferrer" target="_blank">Mastodon</a>. So there's little to do with regards to establishing interoperability in the first place. Beyond that: You can't blindly write a mobile app for these projects without knowing these projects in the first place. They aren't all Twitter-like microblogging services. You need to know that these projects exist. You need to know how they work. You need to know their features. You need to know their specific APIs if they have any. Also, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener noreferrer" target="_blank">Friendica</a> and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener noreferrer" target="_blank">Hubzilla</a> aren't even native #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ActivityPub" rel="nofollow noopener noreferrer" target="_blank">ActivityPub</a> platforms. They have ActivityPub bolted-on as applications. On Hubzilla, you as a user even have to activate ActivityPub on your channel(s). Friendica uses its own protocol internally, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=DFRN" rel="nofollow noopener noreferrer" target="_blank">DFRN</a>, which, along with Friendica, was created eight years before ActivityPub was established as a standard. Hubzilla was created around a protocol named #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot" rel="nofollow noopener noreferrer" target="_blank">Zot</a> which was invented in 2011 and introduced a concept named #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener noreferrer" target="_blank">NomadicIdentity</a>. I can't see ActivityPub being expanded to everything that Hubzilla's current #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot6" rel="nofollow noopener noreferrer" target="_blank">Zot6</a> can do, much less everything that its direct successor, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Nomad" rel="nofollow noopener noreferrer" target="_blank">Nomad</a>, used by #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener noreferrer" target="_blank">Streams</a>, can do. Also, if you wanted to standardise Hubzilla's full feature set in ActivityPub so that app developers can create a mobile app for Hubzilla without ever having seen Hubzilla, you'd have to blow that standard up to gigantic proportions. Since you obviously have never heard of it, let me list up some of its features: <ul><li>cross-instance authorisation via #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener noreferrer" target="_blank">OpenWebAuth</a> (which really only makes sense in a Web browser) </li><li>multiple separate channels per user account with separate identities, each with multiple profiles à la Friendica which can assigned to individual users or privacy groups </li><li>nomadic identity; not only easy moving of channels to other instances, but real-time mirroring of individual channels between multiple instances </li><li>fine-grained privacy/access rights control through both channel roles and pre-definable sets of contact roles </li><li>posts can have an almost unlimited number of characters; formatting is possible through the full standard set of BBcode plus Hubzilla-specific extensions, some of which tie into Zot/OpenWebAuth </li><li>additional long-form writing support through articles which support the same BBcode set </li><li>support for simple webpages which support the same BBcode set plus Markdown plus HTML </li><li>built-in wiki engine which supports BBcode and Markdown plus individual edit access control for other users/channels </li><li>built-in file server with WebDAV support and individual access rights control per directory </li><li>image gallery which can tie into the file server </li><li>public calendar inherited from Friendica </li><li>secondary calendar engine with variable access control for other users/channels and CalDAV support </li><li>address book with CardDAV support </li><li>ca. 55 built-in per-channel applications, most of which are optional </li><li>etc.</li></ul> Let me put it this way: Hubzilla is something which, at its current state, can barely be harnessed in a desktop browser with a hardware mouse, a hardware keyboard and a 20+" display. I can't see Hubzilla's full set of features be made accessible in a mobile app, much less more easily than on the desktop. If you really want to have all features from all Fediverse platforms standardised in ActivityPub, then ActivityPub would end up with three different calendar implementations alone, two of which Hubzilla uses (and they aren't connected to one another in any way), the third being that used by #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mobilizon" rel="nofollow noopener noreferrer" target="_blank">Mobilizon</a>. Besides, I can't even see long-form blogging working on mobile phones. Apps for writing articles on #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Plume" rel="nofollow noopener noreferrer" target="_blank">Plume</a>, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=WriteFreely" rel="nofollow noopener noreferrer" target="_blank">WriteFreely</a> or Hubzilla's article application don't make much sense without a hardware keyboard. Not to mention that Plume, WriteFreely and Hubzilla have different implementations of long-form blog post writing.

Recent searches

Search options

Administered by:

Server stats:

#openwebauth