101010.pl

Jupiter Rowland@<a href="https://mastodon.nzoss.nz/users/strypey" rel="nofollow noopener" target="_blank">Strypey</a> A few more details: <blockquote>* FEP-ef61: Portable Objects <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md" rel="nofollow noopener" target="_blank">https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md</a></blockquote> Invented in, I think, 2023 by @<a href="https://mitra.social/users/silverpill" rel="nofollow noopener" target="_blank">silverpill</a> for <a href="https://codeberg.org/silverpill/mitra" rel="nofollow noopener" target="_blank">Mitra</a> (based on ActivityPub). Currently implemented there and in @<a class="" href="https://fediversity.site/channel/mikedev" rel="nofollow noopener" target="_blank">Mike Macgirvin ?️</a>'s <a href="https://codeberg.org/streams/streams" rel="nofollow noopener" target="_blank">streams repository</a> and <a href="https://codeberg.org/fortified/forte" rel="nofollow noopener" target="_blank">Forte</a>. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub. <blockquote>* FEP-61cf: The OpenWebAuth Protocol <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md" rel="nofollow noopener" target="_blank">https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md</a></blockquote> Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually. CC: @<a href="https://fediversereport.com/author/laurenshof/" rel="nofollow noopener" target="_blank">Laurens Hof</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Long" rel="nofollow noopener" target="_blank">Long</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=LongPost" rel="nofollow noopener" target="_blank">LongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLong" rel="nofollow noopener" target="_blank">CWLong</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLongPost" rel="nofollow noopener" target="_blank">CWLongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediMeta" rel="nofollow noopener" target="_blank">FediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediverseMeta" rel="nofollow noopener" target="_blank">FediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediMeta" rel="nofollow noopener" target="_blank">CWFediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediverseMeta" rel="nofollow noopener" target="_blank">CWFediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener" target="_blank">Fediverse</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener" target="_blank">Friendica</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener" target="_blank">Hubzilla</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zap" rel="nofollow noopener" target="_blank">Zap</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener" target="_blank">Streams</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%28streams%29" rel="nofollow noopener" target="_blank">(streams)</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Forte" rel="nofollow noopener" target="_blank">Forte</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot" rel="nofollow noopener" target="_blank">Zot</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot6" rel="nofollow noopener" target="_blank">Zot6</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Nomad" rel="nofollow noopener" target="_blank">Nomad</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ActivityPub" rel="nofollow noopener" target="_blank">ActivityPub</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FEP" rel="nofollow noopener" target="_blank">FEP</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FEP_ef61" rel="nofollow noopener" target="_blank">FEP_ef61</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FEP_61cf" rel="nofollow noopener" target="_blank">FEP_61cf</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=DecentralizedIdentity" rel="nofollow noopener" target="_blank">DecentralizedIdentity</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener" target="_blank">NomadicIdentity</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=SingleSignOn" rel="nofollow noopener" target="_blank">SingleSignOn</a>

FenTigerAnyone interested in single sign-on / #<a class="" href="https://zotum.net/search?tag=SSO" rel="nofollow noopener" 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" 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" 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" target="_blank">this pull request</a>). <a href="https://mastodon.social/" rel="nofollow noopener" target="_blank">mastodon.social</a> is known to work.</li><li> Hubzilla (any version). <a href="https://zotum.net/" rel="nofollow noopener" target="_blank">zotum.net</a> is known to work.</li><li> <a href="https://indieweb.org/FedCM_for_IndieAuth" rel="nofollow noopener" target="_blank">#</a><a class="" href="https://zotum.net/search?tag=IndieAuth" rel="nofollow noopener" target="_blank">IndieAuth</a> / #<a class="" href="https://zotum.net/search?tag=FedCM" rel="nofollow noopener" 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" target="_blank">#</a><a class="" href="https://zotum.net/search?tag=OIDC" rel="nofollow noopener" target="_blank">OIDC</a> Discovery</li><li> <a href="https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document" rel="nofollow noopener" target="_blank">Client ID Metadata Document</a></li><li> <a href="https://indieweb.org/FedCM_for_IndieAuth" rel="nofollow noopener" 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" target="_blank">#</a><a class="" href="https://zotum.net/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a></li><li> A method using the <a href="https://docs.joinmastodon.org/spec/oauth/" rel="nofollow noopener" target="_blank">Mastodon</a> <a href="https://docs.joinmastodon.org/methods/accounts/#verify_credentials" rel="nofollow noopener" target="_blank">API</a></li><li> <a href="https://indieauth.spec.indieweb.org/" rel="nofollow noopener" 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" 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" 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" 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" 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" target="_blank">Long</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=LongPost" rel="nofollow noopener" target="_blank">LongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLong" rel="nofollow noopener" target="_blank">CWLong</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLongPost" rel="nofollow noopener" target="_blank">CWLongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediMeta" rel="nofollow noopener" target="_blank">FediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediverseMeta" rel="nofollow noopener" target="_blank">FediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediMeta" rel="nofollow noopener" target="_blank">CWFediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediverseMeta" rel="nofollow noopener" target="_blank">CWFediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener" target="_blank">NomadicIdentity</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener" target="_blank">Friendica</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener" target="_blank">Hubzilla</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener" target="_blank">Streams</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%28streams%29" rel="nofollow noopener" target="_blank">(streams)</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ShareButton" rel="nofollow noopener" target="_blank">ShareButton</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ShareButtons" rel="nofollow noopener" target="_blank">ShareButtons</a>

Ecologia Digital<a href="https://mato.social/tags/NomadicIdentity" class="mention hashtag" rel="nofollow noopener" target="_blank">#NomadicIdentity</a>: "<a href="https://mato.social/tags/OpenWebAuth" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenWebAuth</a> used to be called <a href="https://mato.social/tags/MagicAuth" class="mention hashtag" rel="nofollow noopener" 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" 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" 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" translate="no" target="_blank">https://wedistribute.org/2024/03/activitypub-nomadic-identity/</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" 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" 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" 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" 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.

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" 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" 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" 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" target="_blank">Hubzilla</a>. Also available on <a href="https://codeberg.org/streams/streams" rel="nofollow noopener" 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" 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" 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" 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" 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" 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" target="_blank">FEP-1b12</a>, <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/400e/fep-400e.md" rel="nofollow noopener" 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" 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" 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" target="_blank">Lemmy</a> and <a href="https://joinfediverse.wiki/What_is_Kbin%3F" rel="nofollow noopener" 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" 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" 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" target="_blank">Long</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=LongPost" rel="nofollow noopener" target="_blank">LongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLong" rel="nofollow noopener" target="_blank">CWLong</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWLongPost" rel="nofollow noopener" target="_blank">CWLongPost</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediMeta" rel="nofollow noopener" target="_blank">FediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=FediverseMeta" rel="nofollow noopener" target="_blank">FediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediMeta" rel="nofollow noopener" target="_blank">CWFediMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFediverseMeta" rel="nofollow noopener" target="_blank">CWFediverseMeta</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=CWFedisplaining" rel="nofollow noopener" target="_blank">CWFedisplaining</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener" target="_blank">Fediverse</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener" target="_blank">Mastodon</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=MastodonIsNotTheFediverse" rel="nofollow noopener" target="_blank">MastodonIsNotTheFediverse</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NotOnlyMastodon" rel="nofollow noopener" target="_blank">NotOnlyMastodon</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ActivityPub" rel="nofollow noopener" target="_blank">ActivityPub</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener" target="_blank">Friendica</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=DFRN" rel="nofollow noopener" target="_blank">DFRN</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener" target="_blank">Hubzilla</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot" rel="nofollow noopener" target="_blank">Zot</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener" target="_blank">Streams</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%28streams%29" rel="nofollow noopener" target="_blank">(streams)</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Nomad" rel="nofollow noopener" target="_blank">Nomad</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Lemmy" rel="nofollow noopener" target="_blank">Lemmy</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=kbin" rel="nofollow noopener" target="_blank">kbin</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=%2Fkbin" rel="nofollow noopener" target="_blank">/kbin</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener" target="_blank">NomadicIdentity</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Group" rel="nofollow noopener" target="_blank">Group</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Groups" rel="nofollow noopener" target="_blank">Groups</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Forum" rel="nofollow noopener" target="_blank">Forum</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Forums" rel="nofollow noopener" target="_blank">Forums</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Quote" rel="nofollow noopener" target="_blank">Quote</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Quotes" rel="nofollow noopener" target="_blank">Quotes</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Encryption" rel="nofollow noopener" target="_blank">Encryption</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=E2EE" rel="nofollow noopener" target="_blank">E2EE</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=E2EEncryption" rel="nofollow noopener" target="_blank">E2EEncryption</a>

Jupiter Rowland@<a href="https://toots.nu/@jens" rel="nofollow noopener" target="_blank">Jens Ljungkvist :mastodon:</a> @<a href="https://calckey.social/@box464" rel="nofollow noopener" target="_blank">Jeff Sikes</a> @<a href="https://calckey.social/@kainoa" rel="nofollow noopener" target="_blank">Kainoa</a> @<a href="https://calckey.social/@atomicpoet" rel="nofollow noopener" 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" target="_blank">Fediverse</a> projects may adopt #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a>, a #<a class="" href="https://hub.netzgemeinde.eu/search?tag=SingleSignOn" rel="nofollow noopener" target="_blank">SingleSignOn</a> implementation developed by @<a class="" href="https://macgirvin.com/channel/mike" rel="nofollow noopener" target="_blank">mike</a> for #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener" 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" target="_blank">Friendica</a> and its latest not-quite direct descendant, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener" target="_blank">Streams</a>. An implementation is also in development on #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener" target="_blank">Mastodon</a>. It should not be confused with #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OAuth" rel="nofollow noopener" target="_blank">OAuth</a> and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OAuth2" rel="nofollow noopener" 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" target="_blank">CalcKey</a> or #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Lemmy" rel="nofollow noopener" target="_blank">Lemmy</a> or #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mitra" rel="nofollow noopener" 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" 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" 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" 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" target="_blank">Redmatrix</a>, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Osada" rel="nofollow noopener" target="_blank">Osada</a>, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zap" rel="nofollow noopener" target="_blank">Zap</a>, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Misty" rel="nofollow noopener" target="_blank">Misty</a> a.k.a. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mistpark2020" rel="nofollow noopener" target="_blank">Mistpark2020</a> and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Roadhouse" rel="nofollow noopener" target="_blank">Roadhouse</a>. They all speak one native language, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot" rel="nofollow noopener" 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" 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://sfba.social/@CynthesisToday" rel="nofollow noopener" target="_blank">CynthesisToday</a> Yep, these incompatibilities all lie within the #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener" target="_blank">Mastodon</a> server application, how it handles #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ActivityPub" rel="nofollow noopener" target="_blank">ActivityPub</a> and how much of it. There are plenty of Mastodon forks which have things like quotes or text formatting implemented. At least text formatting is trivial to add, mostly by throwing out all the code that strips the rich text formatting off the incoming notes, and quotes aren't rocket science either. The S2C transmission isn't affected by this. However, most mobile apps that were coded against Mastodon either only or first and foremost have neither text formatting nor quotes implemented. Since most Mastodon users are on mobile devices, these features won't appear in practice until the popular mobile apps have them built-in. More general #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener" target="_blank">Fediverse</a> apps or apps designed for other server-side projects have them implemented already now. Oh, and if Mastodon really gets #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a>, then #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Lemmy" rel="nofollow noopener" target="_blank">Lemmy</a> and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=kbin" rel="nofollow noopener" target="_blank">kbin</a> can't sit and watch and pick their noses and do nothing.

Eldarendil<a href="https://social.tchncs.de/@thomholwerda" class="u-url mention" rel="nofollow noopener" target="_blank">@thomholwerda</a> If you want to use a software with the account of another software, they need to support <a href="https://framapiaf.org/tags/OpenWebAuth" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenWebAuth</a> protocol. Currently, all <a href="https://framapiaf.org/tags/Zot" class="mention hashtag" rel="nofollow noopener" target="_blank">#Zot</a> familly (<a href="https://framapiaf.org/tags/Hubzilla" class="mention hashtag" rel="nofollow noopener" target="_blank">#Hubzilla</a>, <a href="https://framapiaf.org/tags/Zap" class="mention hashtag" rel="nofollow noopener" target="_blank">#Zap</a>, <a href="https://framapiaf.org/tags/Stream" class="mention hashtag" rel="nofollow noopener" target="_blank">#Stream</a>...) support it.

Jupiter Rowland@<a href="https://hachyderm.io/@0xSim" rel="nofollow noopener" 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" target="_blank">SingleSignOn</a> in the shape of #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a> (also invented by @<a class="" href="https://macgirvin.com/channel/mike" rel="nofollow noopener" 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 href="https://retrogaming.social/@reflex" rel="nofollow noopener" target="_blank">David Fleetwood - RG Admin</a> I wasn't even talking about #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OAuth" rel="nofollow noopener" target="_blank">OAuth</a>. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a> is something entirely different, created by Friendica inventor <a href="https://macgirvin.com/channel/mike?f=&zid=jupiter_rowland%40hub.netzgemeinde.eu" rel="nofollow noopener" target="_blank">Mike Macgirvin</a> as an advancement for his next creation, Hubzilla, along with a new version of Hubzilla's Zot protocol. That said, Hubzilla also supports both OAuth and OAuth2. But I don't have either token manager app activated on my channel because I don't see a use-case for them right now, so I can't say how or how well they work.

Jupiter Rowland@<a href="https://sfba.social/@markmetz" rel="nofollow noopener" target="_blank">Mr.MarkⓂ️</a> It's already possible to have the same account on multiple instances of the same project, but not on anything based on ActivityPub. It's called #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener" target="_blank">NomadicIdentity</a>, and only #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener" target="_blank">Hubzilla</a>, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener" target="_blank">Streams</a> and the EOL projects in-between have it. Between different projects it only works if they aren't too different. I know someone who has gone nomadic between #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zap" rel="nofollow noopener" target="_blank">Zap</a> and (streams), but EOL Zap can easily be upgraded to (streams), so they're very close. I myself wouldn't dare mirror my Hubzilla channel to (streams). Something else that could be possible is authentication across projects. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a> already made this possible on everything from Hubzilla to (streams), but it's independent from the #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot" rel="nofollow noopener" target="_blank">Zot</a> protocol and could also be used elsewhere. Basically, you log into your channel, and even instances where you don't have an account recognise you by your login credentials. But your proposal, one account for as many instances as you want of as many projects as you want, regardless of underlying technology, I can't see this happen. Either this would require OpenWebAuth to be expanded to such degrees that if I logged into my Hubzilla channel and visit a PeerTube instance, I could upload videos there. This could easily be misused. Or it would require nomadic identity across all kinds of projects and protocols (Zot, DFRN, ActivityPub). I would have to be able to mirror my channel which I now have on two Hubzilla hubs additionally onto four Friendica nodes, five Mastodon servers, three CalcKey instances, two Funkwhale pods, four PeerTube instances, one WordPress blog, one BookWyrm instance and so forth. The very same channel with the very same content, mind you. It should be obvious that this is impossible.

Jupiter Rowland@<a class="" href="https://mastodon.social/@bobwyman" rel="nofollow noopener" 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" target="_blank">Fediverse</a>, but bi-directionally federated with #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener" 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" target="_blank">Friendica</a> and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener" target="_blank">Hubzilla</a> aren't even native #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ActivityPub" rel="nofollow noopener" 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" 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" 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" 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" 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" target="_blank">Nomad</a>, used by #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener" 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" 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" 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" target="_blank">Plume</a>, #<a class="" href="https://hub.netzgemeinde.eu/search?tag=WriteFreely" rel="nofollow noopener" 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.

Jupiter Rowland@<a class="" href="https://loma.ml/profile/z428" rel="nofollow noopener" target="_blank">Kristian</a> @<a class="" href="https://mastodon.social/@atomicpoet" rel="nofollow noopener" target="_blank">Chris Trottier</a> Free, non-corporate, decentralised projects have different intents and purposes than non-free, commercial, corporate, centralised silos. They're created by different people for different people, for different target audiences. And even the huge corporate silos don't start with a shiny iPhone app and then develop the server backend around it. If it's free (as in, for example, Affero GPL), decentralised and distributed, it's made by geeks for geeks first and foremost. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Friendica" rel="nofollow noopener" target="_blank">Friendica</a> first became available in 2010, and unlike Facebook, it never had the intention of becoming the next Internet for everyone in the world. Also, behind Facebook stood a huge megacorporation. Behind Friendica stood only one man, @<a class="" href="https://macgirvin.com/channel/mike" rel="nofollow noopener" target="_blank">mike</a>, all alone, with zero budget. And yet, he managed to release something that was more powerful than Diaspora*, where at the same time only the crowdfunding campaign was running, would ever become. Friendica's target audience were geeks. The same people that also used Linux as their main OS. Friendica wasn't made for the same people as Facebook or the iPhone. In fact, your typical Friendica user wouldn't touch an iPhone or any other Apple product with a 10-foot barge pole. They'd rather have a Nokia N900, and that was a clunky QWERTY slider that ran a modified Debian GNU/Linux. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Redmatrix" rel="nofollow noopener" target="_blank">Redmatrix</a>, the direct successor of Friendica, was experimental. Its sole purpose was to work on the brand-new #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot" rel="nofollow noopener" target="_blank">Zot</a> protocol and the concept of #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener" target="_blank">NomadicIdentity</a>. It still had a small number of users and an even smaller number of instances, but they were generally voluntary guinea pigs. At this time, Friendica was already maintained by its own community which is about as far away from a Silicon Valley gigacorp as you could possibly get. Redmatrix wasn't declared ready for prime time until late 2015 when it was renamed #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener" target="_blank">Hubzilla</a>. And even then, it didn't come with the "vision" of rolling over the mass market and replacing Facebook, WordPress, MediaWiki and the various GAFAM cloud services in one fell swoop. Again, Hubzilla was developed pretty much only by Mike Macgirvin. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Osada" rel="nofollow noopener" target="_blank">Osada</a> and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zap" rel="nofollow noopener" target="_blank">Zap</a> were both largely experimental again. Mike had forked them off Hubzilla because he still wasn't satisfied with what Zot could do at the time. However, the development of the new version #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot6" rel="nofollow noopener" target="_blank">Zot6</a> couldn't happen on that monster named Hubzilla that was in everyday use now. That's why these two new projects were launched. There's a good reason why they were two projects. Zap was there first. Zap was the actual Zot6 testbed, and thus, Zap was Zot6-only. Osada retained compatibility with Friendica and Hubzilla to test how well Zot6 would interact with ActivityPub with had meanwhile appeared as a draft and, IIRC, adopted by both Friendica and Hubzilla. Eventually, Osada and Zap ended up having the exact same codebase, and the difference between the two was an admin switch: ActivityPub on made it Osada, ActivityPub off made it Zap. As this was non-sense, Osada was axed, and Zap got ActivityPub and was declared the next stable one. First, Zap's main killer feature over Hubzilla was Zot6 which had introduced #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a>. When Zot6 was finally backported to Hubzilla, the remaining advantage was that Zap wasn't nearly as bloated with a somewhat less overwhelming UI. By the way, Redmatrix continued to exist with one user until Mike Macgirvin upgraded his own instance to Zap. Now, again, you can't tinker with something that's stable. And tinkering continued. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mistpark" rel="nofollow noopener" target="_blank">Mistpark</a>, Friendica's early name, returned in 2020, as did Redmatrix and Osada, all as Zap forks at various stages of instability and being experimental, none intended for a wider audience. And all created by Mike Macgirvin again. You could happily switch back and forth between Redmatrix, Osada, Zap and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Misty" rel="nofollow noopener" target="_blank">Misty</a> by simply rebasing your server code. (Installing either usually involved "git clone".) He actually had a very good reason for this maze of names: He is opposed to big mass products with big brand identities. He wants to offer people technical solutions, not cool stuff with a sleek brand on it. Anyways, on top of all this came #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Roadhouse" rel="nofollow noopener" target="_blank">Roadhouse</a>, another fork from somewhere in this conglomerate which was created in 2021 and solely intended for the development of the next Zot version, originally named Zot8, now known as #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Nomad" rel="nofollow noopener" target="_blank">Nomad</a>. Roadhouse was so experimental that there has never even been an official text saying what it actually was. Also in 2021 came #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener" target="_blank">Streams</a>, a Roadhouse derivative that started out just as mysterious but was eventually intended for the public. It's often also referred to as (streams) because it's different from its predecessors in one point: It's even less of a brand. It isn't a product to be used as-is. (streams) is not a "Fediverse platform" that's waiting for its own iPhone app. (streams) is <a href="https://codeberg.org/streams/streams" rel="nofollow noopener" target="_blank">a code repository on Codeberg</a>. And its purpose is for others to take the code and make something out of it. It isn't meant to be run as-is, although you can do that, and some people do. And even then, it comes without a fixed brand and kind of asks you to "rebrand" it, even on a per-instance basis. Most (streams)-based instances don't identify as (streams). Mike who is still involved in the project has his own instance based on (streams) but, probably deliberately and intentionally, still has it identify as Zap. Another interesting fact: (streams) uses a wild hodge-podge of free licenses. Most of it is in the public domain, but parts of it are under various free licenses which aren't compatible with each other. This is fully intentional, too. It makes using (streams) for commercial products pretty much impossible because no corporate legal department will be able to figure out how to legally comply with all these licenses at the same time. Free use stays basically unlimited, though. By the way: As of January 1st, 2023, Redmatrix, Osada, Zap, Misty and Roadhouse are EOL and discontinued, and their code repositories were closed. Instances running them can and shall be upgraded to (streams). All that's left is Friendica (the old faithful one), Hubzilla (the nomadic monster) and (streams) (the one for the tinkerers). Now there's still the question: Why do all these projects, in fact including #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener" target="_blank">Mastodon</a>, use this approach? Why do they start with a server platform plus Web frontend instead of doing as big corporations do and start with an iPhone app and develop a server backend around it? Why appeal to a small bunch of Linux nerds rather than to a mass-market of billions? Because if you want to go free and decentralised and distributed and federated, you'll need those Linux nerds before everyone else. First of all, you'll need someone to run instances. Thus, you'll need people who are willing and able to do that. This requires Linux knowledge. The ability to use the command line. The ability to set up and configure a Web server. Network knowledge to connect it to the internet. You can't set up a Web server from zero with three taps on a mobile app. In fact, when Diaspora* was young, it only ran on Mac servers. All four creators were Apple fanbois who didn't care for anything without the Apple brand on it. The Diaspora* server application was built against macOS. The result was a dire lack of public pods (instances) and everyone piling on the official pod. Mac users don't run Web servers at home, and I guess there were no hosting companies that offered Web hosting on Macs. The devs eventually had to make the server app at least halfway Linux-compatible to get more people to run pods, and you still had to compile Ruby on Rails from sources on Debian stable because Diaspora* depended on a newer version. Also, you'll need these tech geeks to spot and report bugs. Your typical Windows or Apple user doesn't report bugs; they only complain about them or switch to a competing product. In stark contrast, many Linux users even know how to file a good and informative bug report. Some are even capable of submitting pull requests with bug-fixing patches through git. And at least in the case of Mike's projects, you'll need a community that's capable of taking over the project itself and continuing its development. You'll need people who know how to code. You'll need people who know how to use git. And so forth. You'll hardly find such people amongst the masses who have spent all their digital lives in the cosy world of corporate-designed GUIs. If, for example, Mastodon had started out with iPhone and Android apps and gone from there, appealing to a rather tech-illiterate mass audience, it would probably never have become decentralised. At least not beyond the federation between mastodon.social, mastodon.online and whatever more instances Eugen Rochko would have had to launch because these two were full. And why not? Because Mastodon wouldn't have appealed to people who know how to install and run Mastodon instances. Mastodon would have only had the Windows/Mac/iPhone/Android crowd as users. All the geeks who would have known how to set up and run a Web server would have stayed on Friendica and Hubzilla. Some may have used ActivityPub to connect to Mastodon, but hardly anyone would have switched to that actually inferior platform with a wholly different crowd on it.

Jupiter Rowland@<a class="" href="https://soapbox.chamba.social/users/aijooyoom" rel="nofollow noopener" target="_blank">aijooyoom</a> @<a class="" href="https://mastodon.social/@atomicpoet" rel="nofollow noopener" target="_blank">Chris Trottier</a> @<a class="" href="https://mastodon.social/@davidslifka" rel="nofollow noopener" target="_blank">David Slifka</a> @<a class="" href="https://venera.social/profile/identity" rel="nofollow noopener" target="_blank">Fediverse Identity Discussion</a> @<a class="" href="https://venera.social/profile/fediversenews" rel="nofollow noopener" target="_blank">Fediverse News</a> Or one could use something that has existed in the #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Fediverse" rel="nofollow noopener" target="_blank">Fediverse</a> for years already: #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot6" rel="nofollow noopener" target="_blank">Zot6</a> or #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Nomad" rel="nofollow noopener" target="_blank">Nomad</a> along with #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a>. #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Zot" rel="nofollow noopener" target="_blank">Zot</a>, the protocol created for #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Hubzilla" rel="nofollow noopener" target="_blank">Hubzilla</a>, introduced #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener" target="_blank">NomadicIdentity</a> a good decade ago. Nomadic identity means you can not only move from instance to instance with ease, but you can have identical, synchronised copies of your channel on as many instances as you want instead of on only one. You always have one "main copy," but your identity is not firmly tied to any one instance. OpenWebAuth, to explain it in brief, transfers your login on supported sites to other supported sites. The OpenWebAuth specs: #^<a class="" href="https://zotlabs.org/page/zot/specs+openwebauth" rel="nofollow noopener" target="_blank">https://zotlabs.org/page/zot/specs+openwebauth</a> And yes, Hubzilla is part of the Fediverse.

Jupiter Rowland@<a class="" href="https://mastodon.social/@atomicpoet" rel="nofollow noopener" target="_blank">Chris Trottier</a> @<a class="" href="https://venera.social/profile/fediversenews" rel="nofollow noopener" target="_blank">Fediverse News</a> #<a class="" href="https://hub.netzgemeinde.eu/search?tag=ActivityPub" rel="nofollow noopener" target="_blank">ActivityPub</a>, as a protocol and its definition, cannot be decentralised any further. There has to be a central steering institution that defines and maintains the protocol to ensure that everything that uses it stays compatible. In practice, however, it's #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Mastodon" rel="nofollow noopener" target="_blank">Mastodon</a> that tries to dictate how everyone else uses ActivityPub. Mastodon has such a big market share that it doesn't have to care for compatibility with anything else, but everything else has to adapt to how Mastodon uses the liberties within ActivityPub. For the other issues, namely more decentralisation and having people own their identity and their data, I'd like to suggest something similar to the #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Freedombox" rel="nofollow noopener" target="_blank">Freedombox</a>, but simplified further. A small computer with Ethernet and Wi-Fi that can serve as your Federated Web home. Instead of Mastodon, it'd run a special concoction brewed from the #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Streams" rel="nofollow noopener" target="_blank">Streams</a> <a href="https://codeberg.org/streams/streams" rel="nofollow noopener" target="_blank">repository</a>, preferably on a Debian stable base system, maybe with the default UI having been replaced with something derived from what's currently being made for Hubzilla. On the one hand, it'd have ActivityPub to connect to the greater Fediverse. On the other hand, it'd have #<a class="" href="https://hub.netzgemeinde.eu/search?tag=Nomad" rel="nofollow noopener" target="_blank">Nomad</a> as its base protocol and offer #<a class="" href="https://hub.netzgemeinde.eu/search?tag=NomadicIdentity" rel="nofollow noopener" target="_blank">NomadicIdentity</a> and #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a> support. The device would come with a USB pen drive with stuff like a PDF manual and various desktop applications for administration, built for Windows, macOS and as a Linux AppImage. Having everyone maintain the underlying system on the command line via ssh would be too much of an obstacle. For those who only own mobile devices, there need to be mobile apps in the Apple App Store, the Google Play Store and on F-Droid that do the same. It shouldn't be the same app for all systems; at least, the iOS app should be under a different license than the Android app which should be under the GPL. Maybe there could be various sizes with different CPUs/APUs and different storage sizes for different purposes. Unfortunately, it won't get any easier than this.

Jupiter Rowland@<a class="" href="https://mas.to/@MetalSamurai" rel="nofollow noopener" target="_blank">Kevin Davidson</a> I guess this could be doable with #<a class="" href="https://hub.netzgemeinde.eu/search?tag=OpenWebAuth" rel="nofollow noopener" target="_blank">OpenWebAuth</a>. Granted, all services involved will have to adopt it first unless they already have it, but they'd have to adopt something anyway. Luckily, we aren't in a situation in which each of these services has its own authentication module, tries hard to make it the global standard and refuses to adopt anything else.

Life is TetrisLament on auth in the Fediverse

bob<a href="https://social.tcit.fr/@tcit" class="u-url mention" rel="nofollow noopener" target="_blank">@tcit</a> <a href="https://diaspodon.fr/@dada" class="u-url mention" rel="nofollow noopener" target="_blank">@dada</a> Réponse courte : RGPD + comptes différents pour les solutions qui contrairement à <a href="https://diaspodon.fr/tags/Hubzilla" class="mention hashtag" rel="nofollow noopener" target="_blank">#Hubzilla</a> ne supportent pas le multi-profile. Réponse longue : dans un monde idéal, on pourrait naviguer sur un site <a href="https://diaspodon.fr/tags/Mobilizion" class="mention hashtag" rel="nofollow noopener" target="_blank">#Mobilizion</a> avec un paramètre <a href="https://diaspodon.fr/tags/OpenWebAuth" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenWebAuth</a> qui permet à la plateforme d'identifier quelle instance et compte on utilise. Ce qui outre permettre des règles de sécu, autorise le pré-remplissage que tu souhaites.

bob<a href="https://microblog.my-freedom.space/@richard" class="u-url mention" rel="nofollow noopener" target="_blank">@richard</a> Pour le SSO et le gestionnaire d'identité, regarde du côté de <a href="https://diaspodon.fr/tags/openwebauth" class="mention hashtag" rel="nofollow noopener" target="_blank">#openWebAuth</a> : c'est déjà implémenté sur <a href="https://diaspodon.fr/tags/hubzilla" class="mention hashtag" rel="nofollow noopener" target="_blank">#Hubzilla</a>, <a href="https://diaspodon.fr/tags/friendica" class="mention hashtag" rel="nofollow noopener" target="_blank">#Friendica</a> et <a href="https://diaspodon.fr/tags/zap" class="mention hashtag" rel="nofollow noopener" target="_blank">#Zap</a>. Et (ce qui va t'intéresser également), la spec va être re-rédigé selon des standards propres dans le groupe de travail <a href="https://www.w3.org/community/zot/" rel="nofollow noopener" target="_blank">https://www.w3.org/community/zot/</a> N'hésite pas à le rejoindre pour pouvoir commenter au plus tôt.

Recent searches

Search options

Administered by:

Server stats:

#openwebauth