DE, EN

  • 0 Posts
  • 20 Comments
Joined 2 years ago
cake
Cake day: September 7th, 2022

help-circle
  • There is also the possiblity of PWA apps (installed from the browser menu, providing the app in the app drawer, and as a share target, with notifications, and all you expect from an app - without the typical baggage of an app, because it’s just a mini wrapper that runs the webpage via the API of your regular browser that is installed anyway).

    To my knowledge, only (streams) offers that, and only the Chrome browser supports it (Firefox is said to be working on it, but I cannot get it to install via Firefox). However, it can be run in other browsers, and Hubzilla offers this option, too - But this is more a kind of PWA lite, you only get a bookmark on the screen (not in the drawer), that calls a dedicated browser window - There is no share target, no notifications, etc.




  • It seems my first message was not delivered, so here it is again (Sorry if it gets double-posted, I will delete the second one if the first one shows up, eventually):

    I’m not sure whether AP has such a mechanism as an instance independent identity (to my knowledge: It does not).

    The Fediverse, however, has: In the Zot (in Hubzilla) or Nomad (in (streams) ) protocol, identity can be moved or cloned between instances. Both (Hubzilla and (streams) ) are compatible with AP, so you can use this ID with most AP platforms - as long as they do not implement a non-standard AP version: Some people call what Mastodon implemented “Mastopub”. But even then, this is more a problem for the other platform’s side like Mastodon, usually the Hubhzilla devs make it work on their platform). Both also have a wide range of functions, so there is hardly and function you cannot participate in using Hubzilla ( (streams) is a bit more limitied for ease of useability, but still offers most relevant functions).

    On these Zot/Nomad platforms, the login for the instance is not your identity. In fact, you can have multiple identities tied to your login. Also, the identity is not your webbie - The webbie is rather an attribute to your ID, like a primary key ID in a database. In fact, it’s rather a link to your ID, so you change have multiple multiple webbies with your ID in parallel. This effectively means, I can login into multiple instances with various accounts, and still access the synchronized content for the independent ID (which is secured against fraud with a personal and foreign key/hash).

    This has been named “nomadic identity” (I prefer portable identity, but I wording is not the key here). All connections / following / subscription within the Zot and Nomad protocol are handled via the ID, not via the webbie. Even non-capable platforms can connect to your primary webbie (which can be freely chosen and shifted…), and the protocoll implementation will deal with all requests to any of the webbies - as long as they exist. When you delete an account or instance, all AP connections are lost (as they, on their side, only know the webbie). All Zot/Nomad connections maintain the connection (as they address the ID which exists independent from / across all instances).

    As I understand it, the Nomad protocol is a transitional step from Zot closer to AP, to demonstrate how AP would be capable to do the same, using the most recent protocol definition. So Mike (the main dev) tries to inspire the AP world to implement this on other platforms.

    This was sent from my Hubzilla ID to Lemmy. I do maintain a Lemmy instance out of curiosity, but I prefer to use Hubzilla for everything. I could register a Mastodon, Pleroma, Funkywhale, or whatever ID on another instance. But what for…?

    BTW: Hubzilla is even compatible with the diaspora* and GNU social protocol, even though at least diaspora seem to not support any compatibility efforts on their side. Hubzilla has been programmed around most of their quirks to make it work, although the do not care. (streams) ditched this burden and focussed on compatibility to Nomad, Zot, and AP.


  • @shrugal

    What we definitely should add is some sort of instance single-sign-on, so you can log into another instance by having your original instance authorize the login attempt.

    In Hubzilla / (streams), that existing functionality is called “remote login” (or technically “OpenWebAuth = OWA”) - and it’s the prerequisite to share access-controlled local content with connections - Unfortunately, this work only with Hubzilla/(streams) identities, because AP does not support this…

    It would be a blast if this mechanism could be transferred to the AP world (after all, it’s freely available open source…) and let us share the local content functions with our AP connections…


  • I’m not sure whether AP has such a mechanism as an instance independent identity (to my knowledge: It does not).

    The Fediverse, however, has: In the Zot (in Hubzilla) or Nomad (in (streams) ) protocol, identity can be moved or cloned between instances. Both (Hubzilla and (streams) ) are compatible with AP, so you can use this ID with most AP platforms - as long as they do not implement a non-standard AP version: Some people call what Mastodon implemented “Mastopub”. But even then, this is more a problem for the other platform’s side like Mastodon, usually the Hubhzilla devs make it work on their platform). Both also have a wide range of functions, so there is hardly and function you cannot participate in using Hubzilla ( (streams) is a bit more limitied for ease of useability, but still offers most relevant functions).

    In this platforms, your login to the instance is not your identity. In fact, you can have multiple identities tied to your login. Also, the identity is not your webbie - The webbie is rather an attribute to your ID, like a primary key ID in a database. In fact, it’s rather a link to your ID, so you change have multiple multiple webbies with your ID in parallel. This effectively means, I can login into multiple instances with various accounts, and still access the synchronized content for the independent ID (which is secured against fraud with a personal and foreign key/hash).

    This has been named “nomadic identity” (I prefer portable identity, but I wording is not the key here). All connections / following / subscription within the Zot and Nomad protocol are handled via the ID, not via the webbie. Even non-capable platforms can connect to your primary webbie (which can be freely chosen and shifted…), and the protocoll implementation will deal with all requests to any of the webbies - as long as they exist. When you delete an account or instance, all AP connections are lost (as they, on their side, only know the webbie). All Zot/Nomad connections maintain the connection (as they address the ID which exists independent from / across all instances).

    As I understand it, the Nomad protocol is a transitional step from Zot closer to AP, to demonstrate how AP would be capable to do the same, using the most recent protocol definition. So Mike (the main dev) tries to inspire the AP world to implement this on other platforms.

    This was sent from my Hubzilla ID to Lemmy. I do maintain a Lemmy instance out of curiosity, but I prefer to use Hubzilla for everything. I could register a Mastodon, Pleroma, Funkywhale, or whatever ID on another instance. But what for…?

    BTW: Hubzilla is even compatible with the diaspora* and GNU social protocol, even though at least diaspora seem to not support any compatibility efforts on their side. Hubzilla has been programmed around most of their quirks to make it work, although the do not care. (streams) ditched this burden and focussed on compatibility to Nomad, Zot, and AP.




  • @nutomic

    Do you know how this kind of federated community search is implemented in terms of Activitypub?

    In case you meant me:
    Hubzilla has its own protocol (Zot) and network, but is interoperable with most of the AP network. But the federated search is implemented by searching the public channels on public instances registered in directory servers (i.e. that want to be found), which is implemented only in Hubzilla servers, so AFAIK, AP contacts have to be entered explicitly by their webbie, instead. The directory servers (I am aware of four) are synchronized, so they are redundant.

    In (streams), AFAIK this was changed to a more implicit search that browses the instances of your ID’s contacts (and contacts of contacts, to a configurable depths - which makes it more decentral, but also more context-/channel-dependent, and consumes more capacity than browsing a central register).

    This search is highly configurable and integrated into the apps’ UI. So you just search from your channel’s interface, and click “add as contact” (which includes group channels => like “subscribe to community”).



  • Interesting indeed… Not sure about all the other points (have not checked), but even if I repeat myself:

    Easy-to-use single-sign-on across servers. Use case: I use several apps for different content types (like micro blog and video). Bonus: they all post from the same identifier

    :ballot_box_with_check:
    OpenWebAuth in Zot (Hubzilla) and Nomad (streams)

    Easy-to-use persona management. Use case: I have a personal and a work account, bonus if they can be on the same server

    :ballot_box_with_check:
    Multiple identities, not only on the same server, but (if you wish so) tied to the same account (same login+credentials) from where they can be switched with a click.

    Plus, in Hubzilla, each identity can have multiple profiles to show to different contact lists (This is a bit over the top, maybe, hardly anyone uses it, but you can show a different faces and profile data to different privacy circles, and post to different pricavy circles, even from the same identity)… Streams skipped that for ease of use.

    Identifiers not tied to the domain name system

    :ballot_box_with_check:
    In Zot & Nomad, every identity has an own address-independent ID+hash which can be cloned to multiple addresses (one of which can be defined as the currently “primary” address, but you can access everything from any clone).

    Sorry, I am aware that I am naming Hubzilla and streams often currently - But it seems the functionality it offers is currently in focus, but not widely known…


  • @nutomic

    There is a pull request up for groups in Mastodon, but it hasnt been updated in a long time. It is also completely incompatible with Lemmy.

    What I honestly do not get is why platforms with evidently less features, more restrictions, and less compatibility get the most attention. Or, to be honest, I think I know: They just promote themselves stronger.

    Mastodon is not that bad. It’s just a shame that they limt the character number. Would be nice to have real groups, too. Oh, and if they could implement good ways of private posting, that would be a blast. While we are at it, they could implement local posts (blogs). Maybe not only blogs, but also photos, videos, and other files. Wikis are not much different from blog posts, either. In fact, you could even implement an add-on system for whatever content to be hosted and shared (webDAV, and calDAV calendars and cardDAV addressbooks would be the icing on the cake). The problem is that most of that content would be hosted on your local instance, so you’d have to add means to authenticate remotely (as in OpenWebAuth) and control read/write persmissions of users on other instances federatedly. Oh, and in case you want to port your identity to a different server, it would be a dream to move all your history and content with you. Or even host your identity synced over multiple instances, so if one is not temporarily or permanently not available, you just switch to another one until it is back online.

    I know, this is all science fiction, but maybe one can hope for some of it to be added to Mastodon within the next two decades… Sorry for the promotional rant for Hubzilla and, with some simplications, also (streams) - which started to provide all that 12 years ago, including the open source code for it, ready for copying from Open Source to other projects.

    There is so much choice in the Fediverse of existing platforms. I wonder why people usually focus on the simple ones and expect them, against their philosophy, to grow into full-featured ones…


  • @_ed

    I wonder how compatible groups will be with other applications.

    That depends how strictly Mastodon (and other applications) stick to AP conventions over defining their own realm in the Fediverse… I’ve seen many discussions in e.g. Hubzilla how devs work persistently around quirky non-standard solutions of other platforms (including diaspora and Mastodon). Sometimes it’s more a matter of philosophy (e.g. dedication to ensuring privacy vs. “we are designed around public posting”, so groups have to be work-arounds for the basic philosophy instead of just a special case of existing privacy by design). Usually, they make it work in the end (at least for the Hubzilla side) - sometimes with a few compromises.

    But I think often it’s a matter of dedication to interoperability attitude vs. platform-centric thinking by design.



  • @maegul Well, it sure outlines that if you want a centrally coordinated approach, a decentral system has it’s drawbacks. One of them being sufficient FLOSS ressources to transform earlier platforms to newer protocols (I am sure Hubzilla devs would not opposed to make the transformation to Nomad - sufficient dev support provided - which I am not so sure about with AP platforms). Anyway, we agree that it would be of much benefit if AP specs provided the existing means for nomadic identity (and if platforms not using it now would incorporate it).

    Unless someone can suggest a better solution, that is.


  • @maegul
    That depends what you expect. Nomadic identity allows you to migrate (or switch) between multiple instances, which keeps your identity quite invulnerable. If you want to switch between social purposes: Hubzilla can do nearly all of them (It’s the swiss army knife of the fediverse). Hubzilla handles all that actually sticks to the AP specification. But AP is not (yet?) capable of doing so, so when you actually migrate an identity for good, you would have to rebuild you AP address book (which is unfortunate, but is caused by lacking features of AP, not by Hubzilla). But you get to keep all your content of all types, and all Zot-(Hubzilla)/Nomad-(streams)-connections. You can even migrate from Hubzilla to the streams platform, but that would be a one-way road because streams has a newer protocol that is “backward-compatible”, but not identical. So you cannot clone or migrate back to Hubzilla. The Nomad protocol is newer with more features (trying to bring Zot functionality implemented with AP means), but the streams server software is more streamlined. So Hubzilla will probably continue to have the far larger population for now.

    But I agree: If AP had picked up the key features Hubzilla / Zot had been created for in the first place (more than a decade ago, actually), that would make the AP galaxies much more future-proof, and thus, the whole Fediverse more powerful.