#nomadicidentity — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #nomadicidentity, aggregated by home.social.
-
@Chao-c'Also, ALT text translates with the rest of the post, which can be helpful for images which contain only foreign language text.
Hubzilla is the most incompatible ActivityPub software in Fediverse. You do just lot of things wrong, to put it mildly.
You still seem to think that Gargron invented ActivityPub and the Fediverse, that Mastodon is the one and only reference implementation of ActivityPub, and that everything that doesn't work exactly like Mastodon is broken.
Here are the facts:
Mastodon was launched in January, 2016.
Hubzilla was launched in March, 2015. Counting an earlier incarnation named Red, it was created in May, 2012, when Friendica's creator re-wrote his own fork of a Friendica fork of his own.
Mastodon implemented ActivityPub in September, 2017, when the spec wasn't finalised yet.
Hubzilla implemented ActivityPub in July, 2017. Two months before Mastodon. Hubzilla was the first software to ever implement ActivityPub.
Hubzilla implemented ActivityPub strictly by the book. It has always tried to stick as close to the official W3C ActivityPub spec as possible.
Mastodon, in stark contrast, has always been stretching the ActivityPub spec until it broke. Not only that, but it has always been adding stuff outside the spec. First it did so to take over certain features from StatusNet which was its original protocol. More recently, it did so with the very intention to break compatibility with the rest of the Fediverse and make everything that isn't Mastodon look broken. And people like you keep falling for it because they think they know for a fact that Mastodon is the ActivityPub reference implementation.
The whole Fediverse has to break the ActivityPub spec just to be able to federate with Mastodon.yes, the Hubzilla author is writing Streams, with nomadic identity, but it also means, that he understands, that Hubzilla approach is kind of dead-end.
You know nothing. Whereas I can rattle down the whole history from Mistpark in 2010 to today.
Mike Macgirvin, creator of Friendica, Hubzilla, (streams) and Forte created his post-Hubzilla server applications because he kept advancing the Zot protocol. And he couldn't implement these advancements into Hubzilla because they bore the chance of breaking compatibility with what already existed.
(streams) is not a completely new development, nor is it a straight Hubzilla fork.
(streams) is a 2022 fork of Roadhouse.
Which was a 2022 fork of either the third Osada or Mistpark 2020 or Redmatrix 2020.
Which were 2020 forks of Zap (or each other, but at least one of them was forked from Zap).
Which was a 2018 fork of either Hubzilla itself or the first Osada, which was a 2018 fork of Hubzilla.
Osada and Zap were created to develop Zot6. In its early stages of concept, Mike expected Zot6 to be incompatible with everything else. Mind you, he didn't see that as something bad. Advancing Zot was necessary because the then-current version of Zot was less than optimal. And Mike's vision was a decentralised, nomadic network named the "Grid", entirely based on Zot. The Grid would have been vastly superior to the existing Fediverse in every way possible.
So the issue with his early draft of Zot6 was that it was quite incompatible with non-nomadic protocols. Nomadic Zot6 content could not be translated into non-nomadic protocols like the diaspora* protocol or ActivityPub.
Thus, developing Zot6 on Hubzilla was out of question. Zot6 would have broken too much on Hubzilla. Besides, Hubzilla was bad as a platform to experiment on due to its wealth of supported protocols and other features, all of which would have had to be made compatible with Zot6.
And this is the real reason why Mike created Osada and Zap. From how I see it, and how I remember what he talked about back in the day (I was there, yes), he first forked Osada from Hubzilla. Then he ripped everything out that he didn't need, including support for all protocols except for Zot itself, ActivityPub, RSS and Atom, including the CMS stuff like articles, planning cards, notes, wikis and webpages, etc. Then he modified what was left against his early version of Zot6.
Then he discovered that a cloned Osada channel couldn't properly send content via ActivityPub.
Then, shortly afterwards, he forked Osada into Zap. He removed nomadic identity from Osada which kept ActivityPub and ActivityPub support from Zap which stayed nomadic.
The idea was to have a nomadic, cloned channel on Zap as your main channel that would only connect to Hubzilla, Osada and Zap, and to have an additional, non-nomadic channel on Osada that would serve as a "gateway" between nomadic Zap and the non-nomadic ActivityPub Fediverse.
Of course, this was highly impractical. But by 2019, Mike found a way to make Zot6 compatible with non-nomadic protocols. So, in early 2019, Mike discontinued Osada and forked a new Osada from Zap which only differred from Zap by having ActivityPub support while still being nomadic. This enabled Mike to have one development platform for Zot6 in conjunction with non-nomadic protocols and another one on which ActivityPub did not stand in the way.
Later in 2019, both Osada and Zap got stable releases. At that point, Osada and Zap were identical in code. Both had ActivityPub support. It was included into their cores now and no longer an add-on like on Hubzilla. They only had two differences. One was the branding. The other one was that Osada servers had ActivityPub activated by default, and Zap servers had ActivityPub disabled by default. Keeping Osada around was unnecessary now, so ActivityPub was activated by default on Zap, and Osada was discontinued. Zot6 was so stable that it was soon backported to Hubzilla.
Mike wasn't done yet, though. He now wanted to develop Zot8. Again, he did not want to develop protocol changes on stable production software that people potentially daily-drove.
Thus, three new forks emerged in 2020: another Osada, Mistpark 2020 (a.k.a. Misty) and Redmatrix 2020 (named after the Red Matrix, the name that Hubzilla bore from late 2012 to early 2015 between being created as Red and being re-branded into Hubzilla). Mike used them to develop Zot8. They were identical in all but brand identity.
This was fully intentional on Mike's part to confuse the hell out of the brand fetishists that were growing more and more numerous in the Fediverse. His goal was for people to declare Osada or Misty or Redmatrix the best Fediverse software and superior to everything else, just for him to tell them that Osada, Misty and Redmatrix are absolutely identical. In fact, the three remained identical to Zap in features.
Zot8 never got stable because Mike kept advancing it further and further. In early 2022, he was at Zot11. But Zot11 was so incompatible with everything else, including previous Zot versions, that Mike declared it a new protocol of its own and renamed it Nomad. In order to test-drive it, he forked Osada or Misty or Redmatrix into Roadhouse. After all, there were people who were daring enough to daily-drive production channels on Osada, Misty and Redmatrix, albeit only few. Roadhouse was still identical in features to Zap, Osada, Misty and Redmatrix.
It was now possible to crossgrade between Zap, Osada, Misty, Redmatrix and Roadhouse by simply rebasing the server code.
Later in 2022, he created a new fork of Roadhouse itself. The reason for this was not further protocol advancement. No, this time, it mostly had branding and licensing reasons.
First of all, he wanted to make that fork as easy for others to fork and adopt as possible. Everything he had developed so far was under the MIT license (he himself had relicensed Friendica under the AGPLv3 in 2011, but he didn't actually develop on Friendica; he developed on a fork named Free-Friendika that was still MIT-licensed and then backported the changes to the Friendica repository, and Red was a Free-Friendika fork). This new repository was released into the public domain. At first, the whole thing was never primarily intended to be installed on servers as it was, but rather to be forked as the base of something new.
At least the core and Mike's own add-ons were. What third-party add-ons from Hubzilla times were still there got to keep their maze of licenses. This was intentional on Mike's part, too. It would make it impossible for commercial players to scoop up the whole thing and relicense it into something non-free and commercial without breaking any licenses, or without pumping tons of money into their legal department to work around that maze of licenses.
Also, Mike removed any and all naming and branding from the software. He absolutely intentionally made it nameless. You've read that right. He did this for two reasons. One, whoever wanted to fork it would have to give the fork an individual name and an individual branding. Two, this was to mess with brand fanbois and brand fetishists even more: This thing had no brand to gush over to begin with.
Furthermore, Mike removed all nodeinfo code that he could possibly get away with removing. Again, this was intentional. One intention was to stop this software from automatically joining the "my Fediverse project is bigger than yours" and "my server is bigger than yours" rat races. He intentionally did everything he could to keep this software away from The Federation, Fediverse Observer, FediDB and the like.
The other intention was for the case of commercial players looking for free code to steal. If this software had really taken off and left its stats proving its popularity everywhere, some big commercial player would have been likely to try and steal this software, make it commercial and non-free and release it as their own original creation. So his intention was for them to not even be able to find it in this case. (This, by the way, was the reason why he relicensed Friendica under the AGPLv3, and why he hardly ever spoke about Free-Friendika: Now that Friendica was growing popular, he didn't want big commercial players to scoop up code of his under a license that they could change to non-free.)
This server application became the first and only one in the Fediverse with no fixed server type identifier, in fact, with none at all by default. It has one text field for the server name, just like Mastodon and Friendica and Hubzilla and the like. But it has an additional field where the server type, i.e. the identifier for the software, can be entered. If none is entered, it's derived from the server name. Mike used to have a server that identified as "Y" because, as he said, "Y is not X."
While the application itself is nameless (for it still is), the code repository did require a name of sorts. Mike named the repository "streams".
Now, the community needed something to call that nameless software when they spoke about it. So they unofficially established "(streams)", complete with parentheses that make sure that this is not actually the name of this software. Those who say, "Streams," with a capital S and no parentheses, and who use that term as if it's an official name, usually sincerely believe that this is the official name.
Mike himself uses "streams" without the parentheses because even he needs something to call his own software by. Before Forte was made, he preferred talking about the streams repository without directly mentioning the software. And he himself denied that (streams) is even a project. It's just a bunch of code that runs.
As far as I know, it was now possible to freely crossgrade between six different server applications because they were still identical in features. Only that Mike also had six server applications to take care of now.
So on December 31st, 2022, Mike discontinued Zap, Osada, Misty, Redmatrix and Roadhouse. Admins who ran either of these on their servers were recommended to rebase their servers to the streams repository. In this case, by the way, the old branding was kept. I've seen a server that still had "zap" as its subdomain which indicated that it was set up as a Zap server, that had Misty branding, but that actually ran (streams).
From then on, Mike dedicated his time to maintaining and developing only the streams repository. He still occasionally helped Hubzilla out, though.
In 2023, the Mitra creator and developer silverpill approached Mike. The goal was to make Mitra nomadic. I guess earlier attempts using a blockchain and crypto technology didn't come to fruition, so it had to be Mike's way which had proven itself stable for more than a decade. However, Mitra was to remain based on ActivityPub.
It was in this exchange that Mike realised that ActivityPub could indeed be used for nomadic identity if a few things were added to it. One outcome was FEP-ef61 "Portable Objects" which introduced decentralised IDs (DIDs) that would not be bound to any one server domain.
Instead of creating a whole new server application to play with, Mike simply made a "nomadic" branch in the streams repository (even though the software was already nomadic) in which he implemented support for nomadic identity via ActivityPub. Support as in (streams) understanding it while internally still using Nomad for nomadicity.
In June, 2024, Mike considered the "nomadic" branch reliable enough and merged it into the "dev" branch.
In July, 2024, Mike merged the "dev" branch into the "release" branch which caused DIDs as per FEP-ef61 to be rolled out to existing production servers. On accounts created on this new version, channels would have a DID internally. On accounts greated on any previous version, even new channels would keep the old ID system for the time being. This way, existing accounts and channels weren't messed with.
However, what had worked under supervised and restricted lab conditions completely blew up under real-life conditions. Again, I was there on (streams) with a pre-DID account and two channels on it. I still have them. (streams) channels wouldn't federate with anything anymore. It had become impossible to send anything anywhere. What Mike was facing was nothing short of an enigma because not even he knew what was going in.
So he started tinkering. In mid-August, Mike forked the streams repository into something named and branded Forte. He did so so he could rip the Nomad protocol out while still keeping the entire functionality. He had to get rid of Nomad because he had discovered that (streams) got confused juggling all the many IDs it had to deal with, so he had to weed out the Nomad and Zot6 IDs to make things easier. But he couldn't possibly have done that on (streams) proper.
This way, Mike created the very first Fediverse server software that uses ActivityPub for full nomadicity, including cloning.
By the end of August, things got back to normal. But Mike, having spent every free minute in the last few weeks to get (streams) back into working condition, was burned out. He sent an open message around in which he declared that he would completely retire from Fediverse development, and both the streams repository and Forte were up for grabs.
But nobody was found who could take over either. (streams) and Forte probably had way fewer than 100 users combined. Those few who would have been able to maintain either didn't have time. One did have time and was willing to do so, but he didn't know how to code. He eventually did start teaching himself, and he occasionally contributes merge requests, but there was no way he could take over as the only dev for either, much less both. So Mike had to go on, whether he wanted or not, albeit at a somewhat slower pace.
This is why Mike is still developing (streams) and Forte to this day.
By the way: The reason why Mike "abandoned" his old software was because he needed to invest all his time into protocol development and advancement. Mike isn't the one to constantly maintain stable server software unless he absolutely has to.
In 2011, he handed Friendica over to two new developers so that he had time to create the Zot protocol.
In 2015 already, he handed Hubzilla over to two new developers so that he had time to explore the advancement of the Zot protocol. He still contributed to Hubzilla's development.
In 2019, he wanted to hand Osada and Zap over to the community, now that they were stable, so he had time to develop Zot8. But the Osada/Zap community was so tiny that he couldn't get a new dedicated developer team together.
In 2024, he wanted to hand (streams) and Forte over to the community because fixing (streams)' huge identity bug, which led to Forte's creation, had burnt him out. He wanted to quit. But, again, he couldn't because (streams) didn't have a single user who had both the time and the knowledge to take over as the new main dev.
Consider this: Gargron was a young man when he made Mastodon. I think he was still at university. Mike Macgirvin made Friendica, he had some three decades of professional work in IT and software under his belly. Gargron was at the beginning of his career. Mike had quit and moved from the USA to the western Australian outback where he has been living as a farmer ever since. He might actually be older than Gargron's parents.while nomadic identitity would be cool thing, currently it does not exist
Take off your Mastodon glasses and look at the Fediverse and what it actually is like.
Nomadic identity does exist. Not as a vague idea, not as a concept on paper, but as a stable, production-grade feature that has been used to its full extent for well over a decade now. Just because Mastodon doesn't have it, doesn't mean the Fediverse doesn't have it. And just because Mastodon doesn't recognise it, doesn't mean it doesn't exist.
The Fediverse has loads of features which Mastodon users want "the Fediverse" to have. It has features which many Mastodon users have never wanted "the Fediverse" to have such as quote-posts, introduced by Mike Macgirvin on Mistpark in 2010. It even has features that are completely and utterly unimaginable for Mastodon users, and it has had even these since as early as 2010, 2012 or 2015.
Nomadic identity was invented by Mike Macgirvin in 2011 with the Zot protocol.
It was first implemented by him in mid-2012 when he rewrote Red against Zot. This means that Hubzilla itself has been offering full-blown nomadic identity since 2012, almost four years longer than Mastodon has existed.
This very Hubzilla channel that I'm commenting from right here, right now, is actually nomadic. It is cloned across two servers: hub.netzgemeinde.eu and hub.hubzilla.de. And it has been since before Elon Musk announced to take over Twitter in early 2022. When I sent you this comment, it was automatically sync'd over to hub.hubzilla.de. When you sent the comment that I'm replying to, it was automatically sync'd over to hub.hubzilla.de. The clone has actually been of great help at least once.
Unfortunately, non-nomadic software identifies cloned channels as fully separate accounts with fully separate identities. But rest assured: @Jupiter Rowland on hub.hubzilla.de is my clone. It's the live, hot, real-time, bidirectional backup of the main instance of my channel, @Jupiter Rowland on hub.netzgemeinde.eu that you're following now. They're both one and the same channel with one and the same identity,[email protected], even though Mastodon is unable to see it as such. Go check both. You'll see they've got all the same content in them, including comments from others. Including your comment. How else can[email protected]possibly have one of your comments under a post if you've only sent that comment to[email protected]if it weren't for nomadic identity?
Even nomadic identity via ActivityPub is available as a stable, production-grade feature in stable, production-grade software right now as we speak. Forte was the first to be fully nomadic via nothing but ActivityPub, as of mid-August, 2024. Tootik, based on Gemini instead of the World Wide Web, is fully nomadic at server level, too. Mitra is fully nomadic by means of the Minimitra client.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentricity #MastodonNormativity #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #ActivityPub #Zot #Zot6 #Zot8 #Nomad #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Mistpark #Mistpark2020 #Misty #Redmatrix2020 #Roadhouse #Streams #(streams) #Forte #Tootik #Mitra #Minimitra #NomadicIdentity -
@Chao-c'Also, ALT text translates with the rest of the post, which can be helpful for images which contain only foreign language text.
Hubzilla is the most incompatible ActivityPub software in Fediverse. You do just lot of things wrong, to put it mildly.
You still seem to think that Gargron invented ActivityPub and the Fediverse, that Mastodon is the one and only reference implementation of ActivityPub, and that everything that doesn't work exactly like Mastodon is broken.
Here are the facts:
Mastodon was launched in January, 2016.
Hubzilla was launched in March, 2015. Counting an earlier incarnation named Red, it was created in May, 2012, when Friendica's creator re-wrote his own fork of a Friendica fork of his own.
Mastodon implemented ActivityPub in September, 2017, when the spec wasn't finalised yet.
Hubzilla implemented ActivityPub in July, 2017. Two months before Mastodon. Hubzilla was the first software to ever implement ActivityPub.
Hubzilla implemented ActivityPub strictly by the book. It has always tried to stick as close to the official W3C ActivityPub spec as possible.
Mastodon, in stark contrast, has always been stretching the ActivityPub spec until it broke. Not only that, but it has always been adding stuff outside the spec. First it did so to take over certain features from StatusNet which was its original protocol. More recently, it did so with the very intention to break compatibility with the rest of the Fediverse and make everything that isn't Mastodon look broken. And people like you keep falling for it because they think they know for a fact that Mastodon is the ActivityPub reference implementation.
The whole Fediverse has to break the ActivityPub spec just to be able to federate with Mastodon.yes, the Hubzilla author is writing Streams, with nomadic identity, but it also means, that he understands, that Hubzilla approach is kind of dead-end.
You know nothing. Whereas I can rattle down the whole history from Mistpark in 2010 to today.
Mike Macgirvin, creator of Friendica, Hubzilla, (streams) and Forte created his post-Hubzilla server applications because he kept advancing the Zot protocol. And he couldn't implement these advancements into Hubzilla because they bore the chance of breaking compatibility with what already existed.
(streams) is not a completely new development, nor is it a straight Hubzilla fork.
(streams) is a 2022 fork of Roadhouse.
Which was a 2022 fork of either the third Osada or Mistpark 2020 or Redmatrix 2020.
Which were 2020 forks of Zap (or each other, but at least one of them was forked from Zap).
Which was a 2018 fork of either Hubzilla itself or the first Osada, which was a 2018 fork of Hubzilla.
Osada and Zap were created to develop Zot6. In its early stages of concept, Mike expected Zot6 to be incompatible with everything else. Mind you, he didn't see that as something bad. Advancing Zot was necessary because the then-current version of Zot was less than optimal. And Mike's vision was a decentralised, nomadic network named the "Grid", entirely based on Zot. The Grid would have been vastly superior to the existing Fediverse in every way possible.
So the issue with his early draft of Zot6 was that it was quite incompatible with non-nomadic protocols. Nomadic Zot6 content could not be translated into non-nomadic protocols like the diaspora* protocol or ActivityPub.
Thus, developing Zot6 on Hubzilla was out of question. Zot6 would have broken too much on Hubzilla. Besides, Hubzilla was bad as a platform to experiment on due to its wealth of supported protocols and other features, all of which would have had to be made compatible with Zot6.
And this is the real reason why Mike created Osada and Zap. From how I see it, and how I remember what he talked about back in the day (I was there, yes), he first forked Osada from Hubzilla. Then he ripped everything out that he didn't need, including support for all protocols except for Zot itself, ActivityPub, RSS and Atom, including the CMS stuff like articles, planning cards, notes, wikis and webpages, etc. Then he modified what was left against his early version of Zot6.
Then he discovered that a cloned Osada channel couldn't properly send content via ActivityPub.
Then, shortly afterwards, he forked Osada into Zap. He removed nomadic identity from Osada which kept ActivityPub and ActivityPub support from Zap which stayed nomadic.
The idea was to have a nomadic, cloned channel on Zap as your main channel that would only connect to Hubzilla, Osada and Zap, and to have an additional, non-nomadic channel on Osada that would serve as a "gateway" between nomadic Zap and the non-nomadic ActivityPub Fediverse.
Of course, this was highly impractical. But by 2019, Mike found a way to make Zot6 compatible with non-nomadic protocols. So, in early 2019, Mike discontinued Osada and forked a new Osada from Zap which only differred from Zap by having ActivityPub support while still being nomadic. This enabled Mike to have one development platform for Zot6 in conjunction with non-nomadic protocols and another one on which ActivityPub did not stand in the way.
Later in 2019, both Osada and Zap got stable releases. At that point, Osada and Zap were identical in code. Both had ActivityPub support. It was included into their cores now and no longer an add-on like on Hubzilla. They only had two differences. One was the branding. The other one was that Osada servers had ActivityPub activated by default, and Zap servers had ActivityPub disabled by default. Keeping Osada around was unnecessary now, so ActivityPub was activated by default on Zap, and Osada was discontinued. Zot6 was so stable that it was soon backported to Hubzilla.
Mike wasn't done yet, though. He now wanted to develop Zot8. Again, he did not want to develop protocol changes on stable production software that people potentially daily-drove.
Thus, three new forks emerged in 2020: another Osada, Mistpark 2020 (a.k.a. Misty) and Redmatrix 2020 (named after the Red Matrix, the name that Hubzilla bore from late 2012 to early 2015 between being created as Red and being re-branded into Hubzilla). Mike used them to develop Zot8. They were identical in all but brand identity.
This was fully intentional on Mike's part to confuse the hell out of the brand fetishists that were growing more and more numerous in the Fediverse. His goal was for people to declare Osada or Misty or Redmatrix the best Fediverse software and superior to everything else, just for him to tell them that Osada, Misty and Redmatrix are absolutely identical. In fact, the three remained identical to Zap in features.
Zot8 never got stable because Mike kept advancing it further and further. In early 2022, he was at Zot11. But Zot11 was so incompatible with everything else, including previous Zot versions, that Mike declared it a new protocol of its own and renamed it Nomad. In order to test-drive it, he forked Osada or Misty or Redmatrix into Roadhouse. After all, there were people who were daring enough to daily-drive production channels on Osada, Misty and Redmatrix, albeit only few. Roadhouse was still identical in features to Zap, Osada, Misty and Redmatrix.
It was now possible to crossgrade between Zap, Osada, Misty, Redmatrix and Roadhouse by simply rebasing the server code.
Later in 2022, he created a new fork of Roadhouse itself. The reason for this was not further protocol advancement. No, this time, it mostly had branding and licensing reasons.
First of all, he wanted to make that fork as easy for others to fork and adopt as possible. Everything he had developed so far was under the MIT license (he himself had relicensed Friendica under the AGPLv3 in 2011, but he didn't actually develop on Friendica; he developed on a fork named Free-Friendika that was still MIT-licensed and then backported the changes to the Friendica repository, and Red was a Free-Friendika fork). This new repository was released into the public domain. At first, the whole thing was never primarily intended to be installed on servers as it was, but rather to be forked as the base of something new.
At least the core and Mike's own add-ons were. What third-party add-ons from Hubzilla times were still there got to keep their maze of licenses. This was intentional on Mike's part, too. It would make it impossible for commercial players to scoop up the whole thing and relicense it into something non-free and commercial without breaking any licenses, or without pumping tons of money into their legal department to work around that maze of licenses.
Also, Mike removed any and all naming and branding from the software. He absolutely intentionally made it nameless. You've read that right. He did this for two reasons. One, whoever wanted to fork it would have to give the fork an individual name and an individual branding. Two, this was to mess with brand fanbois and brand fetishists even more: This thing had no brand to gush over to begin with.
Furthermore, Mike removed all nodeinfo code that he could possibly get away with removing. Again, this was intentional. One intention was to stop this software from automatically joining the "my Fediverse project is bigger than yours" and "my server is bigger than yours" rat races. He intentionally did everything he could to keep this software away from The Federation, Fediverse Observer, FediDB and the like.
The other intention was for the case of commercial players looking for free code to steal. If this software had really taken off and left its stats proving its popularity everywhere, some big commercial player would have been likely to try and steal this software, make it commercial and non-free and release it as their own original creation. So his intention was for them to not even be able to find it in this case. (This, by the way, was the reason why he relicensed Friendica under the AGPLv3, and why he hardly ever spoke about Free-Friendika: Now that Friendica was growing popular, he didn't want big commercial players to scoop up code of his under a license that they could change to non-free.)
This server application became the first and only one in the Fediverse with no fixed server type identifier, in fact, with none at all by default. It has one text field for the server name, just like Mastodon and Friendica and Hubzilla and the like. But it has an additional field where the server type, i.e. the identifier for the software, can be entered. If none is entered, it's derived from the server name. Mike used to have a server that identified as "Y" because, as he said, "Y is not X."
While the application itself is nameless (for it still is), the code repository did require a name of sorts. Mike named the repository "streams".
Now, the community needed something to call that nameless software when they spoke about it. So they unofficially established "(streams)", complete with parentheses that make sure that this is not actually the name of this software. Those who say, "Streams," with a capital S and no parentheses, and who use that term as if it's an official name, usually sincerely believe that this is the official name.
Mike himself uses "streams" without the parentheses because even he needs something to call his own software by. Before Forte was made, he preferred talking about the streams repository without directly mentioning the software. And he himself denied that (streams) is even a project. It's just a bunch of code that runs.
As far as I know, it was now possible to freely crossgrade between six different server applications because they were still identical in features. Only that Mike also had six server applications to take care of now.
So on December 31st, 2022, Mike discontinued Zap, Osada, Misty, Redmatrix and Roadhouse. Admins who ran either of these on their servers were recommended to rebase their servers to the streams repository. In this case, by the way, the old branding was kept. I've seen a server that still had "zap" as its subdomain which indicated that it was set up as a Zap server, that had Misty branding, but that actually ran (streams).
From then on, Mike dedicated his time to maintaining and developing only the streams repository. He still occasionally helped Hubzilla out, though.
In 2023, the Mitra creator and developer silverpill approached Mike. The goal was to make Mitra nomadic. I guess earlier attempts using a blockchain and crypto technology didn't come to fruition, so it had to be Mike's way which had proven itself stable for more than a decade. However, Mitra was to remain based on ActivityPub.
It was in this exchange that Mike realised that ActivityPub could indeed be used for nomadic identity if a few things were added to it. One outcome was FEP-ef61 "Portable Objects" which introduced decentralised IDs (DIDs) that would not be bound to any one server domain.
Instead of creating a whole new server application to play with, Mike simply made a "nomadic" branch in the streams repository (even though the software was already nomadic) in which he implemented support for nomadic identity via ActivityPub. Support as in (streams) understanding it while internally still using Nomad for nomadicity.
In June, 2024, Mike considered the "nomadic" branch reliable enough and merged it into the "dev" branch.
In July, 2024, Mike merged the "dev" branch into the "release" branch which caused DIDs as per FEP-ef61 to be rolled out to existing production servers. On accounts created on this new version, channels would have a DID internally. On accounts greated on any previous version, even new channels would keep the old ID system for the time being. This way, existing accounts and channels weren't messed with.
However, what had worked under supervised and restricted lab conditions completely blew up under real-life conditions. Again, I was there on (streams) with a pre-DID account and two channels on it. I still have them. (streams) channels wouldn't federate with anything anymore. It had become impossible to send anything anywhere. What Mike was facing was nothing short of an enigma because not even he knew what was going in.
So he started tinkering. In mid-August, Mike forked the streams repository into something named and branded Forte. He did so so he could rip the Nomad protocol out while still keeping the entire functionality. He had to get rid of Nomad because he had discovered that (streams) got confused juggling all the many IDs it had to deal with, so he had to weed out the Nomad and Zot6 IDs to make things easier. But he couldn't possibly have done that on (streams) proper.
This way, Mike created the very first Fediverse server software that uses ActivityPub for full nomadicity, including cloning.
By the end of August, things got back to normal. But Mike, having spent every free minute in the last few weeks to get (streams) back into working condition, was burned out. He sent an open message around in which he declared that he would completely retire from Fediverse development, and both the streams repository and Forte were up for grabs.
But nobody was found who could take over either. (streams) and Forte probably had way fewer than 100 users combined. Those few who would have been able to maintain either didn't have time. One did have time and was willing to do so, but he didn't know how to code. He eventually did start teaching himself, and he occasionally contributes merge requests, but there was no way he could take over as the only dev for either, much less both. So Mike had to go on, whether he wanted or not, albeit at a somewhat slower pace.
This is why Mike is still developing (streams) and Forte to this day.
By the way: The reason why Mike "abandoned" his old software was because he needed to invest all his time into protocol development and advancement. Mike isn't the one to constantly maintain stable server software unless he absolutely has to.
In 2011, he handed Friendica over to two new developers so that he had time to create the Zot protocol.
In 2015 already, he handed Hubzilla over to two new developers so that he had time to explore the advancement of the Zot protocol. He still contributed to Hubzilla's development.
In 2019, he wanted to hand Osada and Zap over to the community, now that they were stable, so he had time to develop Zot8. But the Osada/Zap community was so tiny that he couldn't get a new dedicated developer team together.
In 2024, he wanted to hand (streams) and Forte over to the community because fixing (streams)' huge identity bug, which led to Forte's creation, had burnt him out. He wanted to quit. But, again, he couldn't because (streams) didn't have a single user who had both the time and the knowledge to take over as the new main dev.
Consider this: Gargron was a young man when he made Mastodon. I think he was still at university. Mike Macgirvin made Friendica, he had some three decades of professional work in IT and software under his belly. Gargron was at the beginning of his career. Mike had quit and moved from the USA to the western Australian outback where he has been living as a farmer ever since. He might actually be older than Gargron's parents.while nomadic identitity would be cool thing, currently it does not exist
Take off your Mastodon glasses and look at the Fediverse and what it actually is like.
Nomadic identity does exist. Not as a vague idea, not as a concept on paper, but as a stable, production-grade feature that has been used to its full extent for well over a decade now. Just because Mastodon doesn't have it, doesn't mean the Fediverse doesn't have it. And just because Mastodon doesn't recognise it, doesn't mean it doesn't exist.
The Fediverse has loads of features which Mastodon users want "the Fediverse" to have. It has features which many Mastodon users have never wanted "the Fediverse" to have such as quote-posts, introduced by Mike Macgirvin on Mistpark in 2010. It even has features that are completely and utterly unimaginable for Mastodon users, and it has had even these since as early as 2010, 2012 or 2015.
Nomadic identity was invented by Mike Macgirvin in 2011 with the Zot protocol.
It was first implemented by him in mid-2012 when he rewrote Red against Zot. This means that Hubzilla itself has been offering full-blown nomadic identity since 2012, almost four years longer than Mastodon has existed.
This very Hubzilla channel that I'm commenting from right here, right now, is actually nomadic. It is cloned across two servers: hub.netzgemeinde.eu and hub.hubzilla.de. And it has been since before Elon Musk announced to take over Twitter in early 2022. When I sent you this comment, it was automatically sync'd over to hub.hubzilla.de. When you sent the comment that I'm replying to, it was automatically sync'd over to hub.hubzilla.de. The clone has actually been of great help at least once.
Unfortunately, non-nomadic software identifies cloned channels as fully separate accounts with fully separate identities. But rest assured: @Jupiter Rowland on hub.hubzilla.de is my clone. It's the live, hot, real-time, bidirectional backup of the main instance of my channel, @Jupiter Rowland on hub.netzgemeinde.eu that you're following now. They're both one and the same channel with one and the same identity,[email protected], even though Mastodon is unable to see it as such. Go check both. You'll see they've got all the same content in them, including comments from others. Including your comment. How else can[email protected]possibly have one of your comments under a post if you've only sent that comment to[email protected]if it weren't for nomadic identity?
Even nomadic identity via ActivityPub is available as a stable, production-grade feature in stable, production-grade software right now as we speak. Forte was the first to be fully nomadic via nothing but ActivityPub, as of mid-August, 2024. Tootik, based on Gemini instead of the World Wide Web, is fully nomadic at server level, too. Mitra is fully nomadic by means of the Minimitra client.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentricity #MastodonNormativity #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #ActivityPub #Zot #Zot6 #Zot8 #Nomad #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Mistpark #Mistpark2020 #Misty #Redmatrix2020 #Roadhouse #Streams #(streams) #Forte #Tootik #Mitra #Minimitra #NomadicIdentity -
@Chao-c'Also, ALT text translates with the rest of the post, which can be helpful for images which contain only foreign language text.
Hubzilla is the most incompatible ActivityPub software in Fediverse. You do just lot of things wrong, to put it mildly.
You still seem to think that Gargron invented ActivityPub and the Fediverse, that Mastodon is the one and only reference implementation of ActivityPub, and that everything that doesn't work exactly like Mastodon is broken.
Here are the facts:
Mastodon was launched in January, 2016.
Hubzilla was launched in March, 2015. Counting an earlier incarnation named Red, it was created in May, 2012, when Friendica's creator re-wrote his own fork of a Friendica fork of his own.
Mastodon implemented ActivityPub in September, 2017, when the spec wasn't finalised yet.
Hubzilla implemented ActivityPub in July, 2017. Two months before Mastodon. Hubzilla was the first software to ever implement ActivityPub.
Hubzilla implemented ActivityPub strictly by the book. It has always tried to stick as close to the official W3C ActivityPub spec as possible.
Mastodon, in stark contrast, has always been stretching the ActivityPub spec until it broke. Not only that, but it has always been adding stuff outside the spec. First it did so to take over certain features from StatusNet which was its original protocol. More recently, it did so with the very intention to break compatibility with the rest of the Fediverse and make everything that isn't Mastodon look broken. And people like you keep falling for it because they think they know for a fact that Mastodon is the ActivityPub reference implementation.
The whole Fediverse has to break the ActivityPub spec just to be able to federate with Mastodon.yes, the Hubzilla author is writing Streams, with nomadic identity, but it also means, that he understands, that Hubzilla approach is kind of dead-end.
You know nothing. Whereas I can rattle down the whole history from Mistpark in 2010 to today.
Mike Macgirvin, creator of Friendica, Hubzilla, (streams) and Forte created his post-Hubzilla server applications because he kept advancing the Zot protocol. And he couldn't implement these advancements into Hubzilla because they bore the chance of breaking compatibility with what already existed.
(streams) is not a completely new development, nor is it a straight Hubzilla fork.
(streams) is a 2022 fork of Roadhouse.
Which was a 2022 fork of either the third Osada or Mistpark 2020 or Redmatrix 2020.
Which were 2020 forks of Zap (or each other, but at least one of them was forked from Zap).
Which was a 2018 fork of either Hubzilla itself or the first Osada, which was a 2018 fork of Hubzilla.
Osada and Zap were created to develop Zot6. In its early stages of concept, Mike expected Zot6 to be incompatible with everything else. Mind you, he didn't see that as something bad. Advancing Zot was necessary because the then-current version of Zot was less than optimal. And Mike's vision was a decentralised, nomadic network named the "Grid", entirely based on Zot. The Grid would have been vastly superior to the existing Fediverse in every way possible.
So the issue with his early draft of Zot6 was that it was quite incompatible with non-nomadic protocols. Nomadic Zot6 content could not be translated into non-nomadic protocols like the diaspora* protocol or ActivityPub.
Thus, developing Zot6 on Hubzilla was out of question. Zot6 would have broken too much on Hubzilla. Besides, Hubzilla was bad as a platform to experiment on due to its wealth of supported protocols and other features, all of which would have had to be made compatible with Zot6.
And this is the real reason why Mike created Osada and Zap. From how I see it, and how I remember what he talked about back in the day (I was there, yes), he first forked Osada from Hubzilla. Then he ripped everything out that he didn't need, including support for all protocols except for Zot itself, ActivityPub, RSS and Atom, including the CMS stuff like articles, planning cards, notes, wikis and webpages, etc. Then he modified what was left against his early version of Zot6.
Then he discovered that a cloned Osada channel couldn't properly send content via ActivityPub.
Then, shortly afterwards, he forked Osada into Zap. He removed nomadic identity from Osada which kept ActivityPub and ActivityPub support from Zap which stayed nomadic.
The idea was to have a nomadic, cloned channel on Zap as your main channel that would only connect to Hubzilla, Osada and Zap, and to have an additional, non-nomadic channel on Osada that would serve as a "gateway" between nomadic Zap and the non-nomadic ActivityPub Fediverse.
Of course, this was highly impractical. But by 2019, Mike found a way to make Zot6 compatible with non-nomadic protocols. So, in early 2019, Mike discontinued Osada and forked a new Osada from Zap which only differred from Zap by having ActivityPub support while still being nomadic. This enabled Mike to have one development platform for Zot6 in conjunction with non-nomadic protocols and another one on which ActivityPub did not stand in the way.
Later in 2019, both Osada and Zap got stable releases. At that point, Osada and Zap were identical in code. Both had ActivityPub support. It was included into their cores now and no longer an add-on like on Hubzilla. They only had two differences. One was the branding. The other one was that Osada servers had ActivityPub activated by default, and Zap servers had ActivityPub disabled by default. Keeping Osada around was unnecessary now, so ActivityPub was activated by default on Zap, and Osada was discontinued. Zot6 was so stable that it was soon backported to Hubzilla.
Mike wasn't done yet, though. He now wanted to develop Zot8. Again, he did not want to develop protocol changes on stable production software that people potentially daily-drove.
Thus, three new forks emerged in 2020: another Osada, Mistpark 2020 (a.k.a. Misty) and Redmatrix 2020 (named after the Red Matrix, the name that Hubzilla bore from late 2012 to early 2015 between being created as Red and being re-branded into Hubzilla). Mike used them to develop Zot8. They were identical in all but brand identity.
This was fully intentional on Mike's part to confuse the hell out of the brand fetishists that were growing more and more numerous in the Fediverse. His goal was for people to declare Osada or Misty or Redmatrix the best Fediverse software and superior to everything else, just for him to tell them that Osada, Misty and Redmatrix are absolutely identical. In fact, the three remained identical to Zap in features.
Zot8 never got stable because Mike kept advancing it further and further. In early 2022, he was at Zot11. But Zot11 was so incompatible with everything else, including previous Zot versions, that Mike declared it a new protocol of its own and renamed it Nomad. In order to test-drive it, he forked Osada or Misty or Redmatrix into Roadhouse. After all, there were people who were daring enough to daily-drive production channels on Osada, Misty and Redmatrix, albeit only few. Roadhouse was still identical in features to Zap, Osada, Misty and Redmatrix.
It was now possible to crossgrade between Zap, Osada, Misty, Redmatrix and Roadhouse by simply rebasing the server code.
Later in 2022, he created a new fork of Roadhouse itself. The reason for this was not further protocol advancement. No, this time, it mostly had branding and licensing reasons.
First of all, he wanted to make that fork as easy for others to fork and adopt as possible. Everything he had developed so far was under the MIT license (he himself had relicensed Friendica under the AGPLv3 in 2011, but he didn't actually develop on Friendica; he developed on a fork named Free-Friendika that was still MIT-licensed and then backported the changes to the Friendica repository, and Red was a Free-Friendika fork). This new repository was released into the public domain. At first, the whole thing was never primarily intended to be installed on servers as it was, but rather to be forked as the base of something new.
At least the core and Mike's own add-ons were. What third-party add-ons from Hubzilla times were still there got to keep their maze of licenses. This was intentional on Mike's part, too. It would make it impossible for commercial players to scoop up the whole thing and relicense it into something non-free and commercial without breaking any licenses, or without pumping tons of money into their legal department to work around that maze of licenses.
Also, Mike removed any and all naming and branding from the software. He absolutely intentionally made it nameless. You've read that right. He did this for two reasons. One, whoever wanted to fork it would have to give the fork an individual name and an individual branding. Two, this was to mess with brand fanbois and brand fetishists even more: This thing had no brand to gush over to begin with.
Furthermore, Mike removed all nodeinfo code that he could possibly get away with removing. Again, this was intentional. One intention was to stop this software from automatically joining the "my Fediverse project is bigger than yours" and "my server is bigger than yours" rat races. He intentionally did everything he could to keep this software away from The Federation, Fediverse Observer, FediDB and the like.
The other intention was for the case of commercial players looking for free code to steal. If this software had really taken off and left its stats proving its popularity everywhere, some big commercial player would have been likely to try and steal this software, make it commercial and non-free and release it as their own original creation. So his intention was for them to not even be able to find it in this case. (This, by the way, was the reason why he relicensed Friendica under the AGPLv3, and why he hardly ever spoke about Free-Friendika: Now that Friendica was growing popular, he didn't want big commercial players to scoop up code of his under a license that they could change to non-free.)
This server application became the first and only one in the Fediverse with no fixed server type identifier, in fact, with none at all by default. It has one text field for the server name, just like Mastodon and Friendica and Hubzilla and the like. But it has an additional field where the server type, i.e. the identifier for the software, can be entered. If none is entered, it's derived from the server name. Mike used to have a server that identified as "Y" because, as he said, "Y is not X."
While the application itself is nameless (for it still is), the code repository did require a name of sorts. Mike named the repository "streams".
Now, the community needed something to call that nameless software when they spoke about it. So they unofficially established "(streams)", complete with parentheses that make sure that this is not actually the name of this software. Those who say, "Streams," with a capital S and no parentheses, and who use that term as if it's an official name, usually sincerely believe that this is the official name.
Mike himself uses "streams" without the parentheses because even he needs something to call his own software by. Before Forte was made, he preferred talking about the streams repository without directly mentioning the software. And he himself denied that (streams) is even a project. It's just a bunch of code that runs.
As far as I know, it was now possible to freely crossgrade between six different server applications because they were still identical in features. Only that Mike also had six server applications to take care of now.
So on December 31st, 2022, Mike discontinued Zap, Osada, Misty, Redmatrix and Roadhouse. Admins who ran either of these on their servers were recommended to rebase their servers to the streams repository. In this case, by the way, the old branding was kept. I've seen a server that still had "zap" as its subdomain which indicated that it was set up as a Zap server, that had Misty branding, but that actually ran (streams).
From then on, Mike dedicated his time to maintaining and developing only the streams repository. He still occasionally helped Hubzilla out, though.
In 2023, the Mitra creator and developer silverpill approached Mike. The goal was to make Mitra nomadic. I guess earlier attempts using a blockchain and crypto technology didn't come to fruition, so it had to be Mike's way which had proven itself stable for more than a decade. However, Mitra was to remain based on ActivityPub.
It was in this exchange that Mike realised that ActivityPub could indeed be used for nomadic identity if a few things were added to it. One outcome was FEP-ef61 "Portable Objects" which introduced decentralised IDs (DIDs) that would not be bound to any one server domain.
Instead of creating a whole new server application to play with, Mike simply made a "nomadic" branch in the streams repository (even though the software was already nomadic) in which he implemented support for nomadic identity via ActivityPub. Support as in (streams) understanding it while internally still using Nomad for nomadicity.
In June, 2024, Mike considered the "nomadic" branch reliable enough and merged it into the "dev" branch.
In July, 2024, Mike merged the "dev" branch into the "release" branch which caused DIDs as per FEP-ef61 to be rolled out to existing production servers. On accounts created on this new version, channels would have a DID internally. On accounts greated on any previous version, even new channels would keep the old ID system for the time being. This way, existing accounts and channels weren't messed with.
However, what had worked under supervised and restricted lab conditions completely blew up under real-life conditions. Again, I was there on (streams) with a pre-DID account and two channels on it. I still have them. (streams) channels wouldn't federate with anything anymore. It had become impossible to send anything anywhere. What Mike was facing was nothing short of an enigma because not even he knew what was going in.
So he started tinkering. In mid-August, Mike forked the streams repository into something named and branded Forte. He did so so he could rip the Nomad protocol out while still keeping the entire functionality. He had to get rid of Nomad because he had discovered that (streams) got confused juggling all the many IDs it had to deal with, so he had to weed out the Nomad and Zot6 IDs to make things easier. But he couldn't possibly have done that on (streams) proper.
This way, Mike created the very first Fediverse server software that uses ActivityPub for full nomadicity, including cloning.
By the end of August, things got back to normal. But Mike, having spent every free minute in the last few weeks to get (streams) back into working condition, was burned out. He sent an open message around in which he declared that he would completely retire from Fediverse development, and both the streams repository and Forte were up for grabs.
But nobody was found who could take over either. (streams) and Forte probably had way fewer than 100 users combined. Those few who would have been able to maintain either didn't have time. One did have time and was willing to do so, but he didn't know how to code. He eventually did start teaching himself, and he occasionally contributes merge requests, but there was no way he could take over as the only dev for either, much less both. So Mike had to go on, whether he wanted or not, albeit at a somewhat slower pace.
This is why Mike is still developing (streams) and Forte to this day.
By the way: The reason why Mike "abandoned" his old software was because he needed to invest all his time into protocol development and advancement. Mike isn't the one to constantly maintain stable server software unless he absolutely has to.
In 2011, he handed Friendica over to two new developers so that he had time to create the Zot protocol.
In 2015 already, he handed Hubzilla over to two new developers so that he had time to explore the advancement of the Zot protocol. He still contributed to Hubzilla's development.
In 2019, he wanted to hand Osada and Zap over to the community, now that they were stable, so he had time to develop Zot8. But the Osada/Zap community was so tiny that he couldn't get a new dedicated developer team together.
In 2024, he wanted to hand (streams) and Forte over to the community because fixing (streams)' huge identity bug, which led to Forte's creation, had burnt him out. He wanted to quit. But, again, he couldn't because (streams) didn't have a single user who had both the time and the knowledge to take over as the new main dev.
Consider this: Gargron was a young man when he made Mastodon. I think he was still at university. Mike Macgirvin made Friendica, he had some three decades of professional work in IT and software under his belly. Gargron was at the beginning of his career. Mike had quit and moved from the USA to the western Australian outback where he has been living as a farmer ever since. He might actually be older than Gargron's parents.while nomadic identitity would be cool thing, currently it does not exist
Take off your Mastodon glasses and look at the Fediverse and what it actually is like.
Nomadic identity does exist. Not as a vague idea, not as a concept on paper, but as a stable, production-grade feature that has been used to its full extent for well over a decade now. Just because Mastodon doesn't have it, doesn't mean the Fediverse doesn't have it. And just because Mastodon doesn't recognise it, doesn't mean it doesn't exist.
The Fediverse has loads of features which Mastodon users want "the Fediverse" to have. It has features which many Mastodon users have never wanted "the Fediverse" to have such as quote-posts, introduced by Mike Macgirvin on Mistpark in 2010. It even has features that are completely and utterly unimaginable for Mastodon users, and it has had even these since as early as 2010, 2012 or 2015.
Nomadic identity was invented by Mike Macgirvin in 2011 with the Zot protocol.
It was first implemented by him in mid-2012 when he rewrote Red against Zot. This means that Hubzilla itself has been offering full-blown nomadic identity since 2012, almost four years longer than Mastodon has existed.
This very Hubzilla channel that I'm commenting from right here, right now, is actually nomadic. It is cloned across two servers: hub.netzgemeinde.eu and hub.hubzilla.de. And it has been since before Elon Musk announced to take over Twitter in early 2022. When I sent you this comment, it was automatically sync'd over to hub.hubzilla.de. When you sent the comment that I'm replying to, it was automatically sync'd over to hub.hubzilla.de. The clone has actually been of great help at least once.
Unfortunately, non-nomadic software identifies cloned channels as fully separate accounts with fully separate identities. But rest assured: @Jupiter Rowland on hub.hubzilla.de is my clone. It's the live, hot, real-time, bidirectional backup of the main instance of my channel, @Jupiter Rowland on hub.netzgemeinde.eu that you're following now. They're both one and the same channel with one and the same identity,[email protected], even though Mastodon is unable to see it as such. Go check both. You'll see they've got all the same content in them, including comments from others. Including your comment. How else can[email protected]possibly have one of your comments under a post if you've only sent that comment to[email protected]if it weren't for nomadic identity?
Even nomadic identity via ActivityPub is available as a stable, production-grade feature in stable, production-grade software right now as we speak. Forte was the first to be fully nomadic via nothing but ActivityPub, as of mid-August, 2024. Tootik, based on Gemini instead of the World Wide Web, is fully nomadic at server level, too. Mitra is fully nomadic by means of the Minimitra client.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentricity #MastodonNormativity #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #ActivityPub #Zot #Zot6 #Zot8 #Nomad #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Mistpark #Mistpark2020 #Misty #Redmatrix2020 #Roadhouse #Streams #(streams) #Forte #Tootik #Mitra #Minimitra #NomadicIdentity -
@Chao-c'Also, ALT text translates with the rest of the post, which can be helpful for images which contain only foreign language text.
Hubzilla is the most incompatible ActivityPub software in Fediverse. You do just lot of things wrong, to put it mildly.
You still seem to think that Gargron invented ActivityPub and the Fediverse, that Mastodon is the one and only reference implementation of ActivityPub, and that everything that doesn't work exactly like Mastodon is broken.
Here are the facts:
Mastodon was launched in January, 2016.
Hubzilla was launched in March, 2015. Counting an earlier incarnation named Red, it was created in May, 2012, when Friendica's creator re-wrote his own fork of a Friendica fork of his own.
Mastodon implemented ActivityPub in September, 2017, when the spec wasn't finalised yet.
Hubzilla implemented ActivityPub in July, 2017. Two months before Mastodon. Hubzilla was the first software to ever implement ActivityPub.
Hubzilla implemented ActivityPub strictly by the book. It has always tried to stick as close to the official W3C ActivityPub spec as possible.
Mastodon, in stark contrast, has always been stretching the ActivityPub spec until it broke. Not only that, but it has always been adding stuff outside the spec. First it did so to take over certain features from StatusNet which was its original protocol. More recently, it did so with the very intention to break compatibility with the rest of the Fediverse and make everything that isn't Mastodon look broken. And people like you keep falling for it because they think they know for a fact that Mastodon is the ActivityPub reference implementation.
The whole Fediverse has to break the ActivityPub spec just to be able to federate with Mastodon.yes, the Hubzilla author is writing Streams, with nomadic identity, but it also means, that he understands, that Hubzilla approach is kind of dead-end.
You know nothing. Whereas I can rattle down the whole history from Mistpark in 2010 to today.
Mike Macgirvin, creator of Friendica, Hubzilla, (streams) and Forte created his post-Hubzilla server applications because he kept advancing the Zot protocol. And he couldn't implement these advancements into Hubzilla because they bore the chance of breaking compatibility with what already existed.
(streams) is not a completely new development, nor is it a straight Hubzilla fork.
(streams) is a 2022 fork of Roadhouse.
Which was a 2022 fork of either the third Osada or Mistpark 2020 or Redmatrix 2020.
Which were 2020 forks of Zap (or each other, but at least one of them was forked from Zap).
Which was a 2018 fork of either Hubzilla itself or the first Osada, which was a 2018 fork of Hubzilla.
Osada and Zap were created to develop Zot6. In its early stages of concept, Mike expected Zot6 to be incompatible with everything else. Mind you, he didn't see that as something bad. Advancing Zot was necessary because the then-current version of Zot was less than optimal. And Mike's vision was a decentralised, nomadic network named the "Grid", entirely based on Zot. The Grid would have been vastly superior to the existing Fediverse in every way possible.
So the issue with his early draft of Zot6 was that it was quite incompatible with non-nomadic protocols. Nomadic Zot6 content could not be translated into non-nomadic protocols like the diaspora* protocol or ActivityPub.
Thus, developing Zot6 on Hubzilla was out of question. Zot6 would have broken too much on Hubzilla. Besides, Hubzilla was bad as a platform to experiment on due to its wealth of supported protocols and other features, all of which would have had to be made compatible with Zot6.
And this is the real reason why Mike created Osada and Zap. From how I see it, and how I remember what he talked about back in the day (I was there, yes), he first forked Osada from Hubzilla. Then he ripped everything out that he didn't need, including support for all protocols except for Zot itself, ActivityPub, RSS and Atom, including the CMS stuff like articles, planning cards, notes, wikis and webpages, etc. Then he modified what was left against his early version of Zot6.
Then he discovered that a cloned Osada channel couldn't properly send content via ActivityPub.
Then, shortly afterwards, he forked Osada into Zap. He removed nomadic identity from Osada which kept ActivityPub and ActivityPub support from Zap which stayed nomadic.
The idea was to have a nomadic, cloned channel on Zap as your main channel that would only connect to Hubzilla, Osada and Zap, and to have an additional, non-nomadic channel on Osada that would serve as a "gateway" between nomadic Zap and the non-nomadic ActivityPub Fediverse.
Of course, this was highly impractical. But by 2019, Mike found a way to make Zot6 compatible with non-nomadic protocols. So, in early 2019, Mike discontinued Osada and forked a new Osada from Zap which only differred from Zap by having ActivityPub support while still being nomadic. This enabled Mike to have one development platform for Zot6 in conjunction with non-nomadic protocols and another one on which ActivityPub did not stand in the way.
Later in 2019, both Osada and Zap got stable releases. At that point, Osada and Zap were identical in code. Both had ActivityPub support. It was included into their cores now and no longer an add-on like on Hubzilla. They only had two differences. One was the branding. The other one was that Osada servers had ActivityPub activated by default, and Zap servers had ActivityPub disabled by default. Keeping Osada around was unnecessary now, so ActivityPub was activated by default on Zap, and Osada was discontinued. Zot6 was so stable that it was soon backported to Hubzilla.
Mike wasn't done yet, though. He now wanted to develop Zot8. Again, he did not want to develop protocol changes on stable production software that people potentially daily-drove.
Thus, three new forks emerged in 2020: another Osada, Mistpark 2020 (a.k.a. Misty) and Redmatrix 2020 (named after the Red Matrix, the name that Hubzilla bore from late 2012 to early 2015 between being created as Red and being re-branded into Hubzilla). Mike used them to develop Zot8. They were identical in all but brand identity.
This was fully intentional on Mike's part to confuse the hell out of the brand fetishists that were growing more and more numerous in the Fediverse. His goal was for people to declare Osada or Misty or Redmatrix the best Fediverse software and superior to everything else, just for him to tell them that Osada, Misty and Redmatrix are absolutely identical. In fact, the three remained identical to Zap in features.
Zot8 never got stable because Mike kept advancing it further and further. In early 2022, he was at Zot11. But Zot11 was so incompatible with everything else, including previous Zot versions, that Mike declared it a new protocol of its own and renamed it Nomad. In order to test-drive it, he forked Osada or Misty or Redmatrix into Roadhouse. After all, there were people who were daring enough to daily-drive production channels on Osada, Misty and Redmatrix, albeit only few. Roadhouse was still identical in features to Zap, Osada, Misty and Redmatrix.
It was now possible to crossgrade between Zap, Osada, Misty, Redmatrix and Roadhouse by simply rebasing the server code.
Later in 2022, he created a new fork of Roadhouse itself. The reason for this was not further protocol advancement. No, this time, it mostly had branding and licensing reasons.
First of all, he wanted to make that fork as easy for others to fork and adopt as possible. Everything he had developed so far was under the MIT license (he himself had relicensed Friendica under the AGPLv3 in 2011, but he didn't actually develop on Friendica; he developed on a fork named Free-Friendika that was still MIT-licensed and then backported the changes to the Friendica repository, and Red was a Free-Friendika fork). This new repository was released into the public domain. At first, the whole thing was never primarily intended to be installed on servers as it was, but rather to be forked as the base of something new.
At least the core and Mike's own add-ons were. What third-party add-ons from Hubzilla times were still there got to keep their maze of licenses. This was intentional on Mike's part, too. It would make it impossible for commercial players to scoop up the whole thing and relicense it into something non-free and commercial without breaking any licenses, or without pumping tons of money into their legal department to work around that maze of licenses.
Also, Mike removed any and all naming and branding from the software. He absolutely intentionally made it nameless. You've read that right. He did this for two reasons. One, whoever wanted to fork it would have to give the fork an individual name and an individual branding. Two, this was to mess with brand fanbois and brand fetishists even more: This thing had no brand to gush over to begin with.
Furthermore, Mike removed all nodeinfo code that he could possibly get away with removing. Again, this was intentional. One intention was to stop this software from automatically joining the "my Fediverse project is bigger than yours" and "my server is bigger than yours" rat races. He intentionally did everything he could to keep this software away from The Federation, Fediverse Observer, FediDB and the like.
The other intention was for the case of commercial players looking for free code to steal. If this software had really taken off and left its stats proving its popularity everywhere, some big commercial player would have been likely to try and steal this software, make it commercial and non-free and release it as their own original creation. So his intention was for them to not even be able to find it in this case. (This, by the way, was the reason why he relicensed Friendica under the AGPLv3, and why he hardly ever spoke about Free-Friendika: Now that Friendica was growing popular, he didn't want big commercial players to scoop up code of his under a license that they could change to non-free.)
This server application became the first and only one in the Fediverse with no fixed server type identifier, in fact, with none at all by default. It has one text field for the server name, just like Mastodon and Friendica and Hubzilla and the like. But it has an additional field where the server type, i.e. the identifier for the software, can be entered. If none is entered, it's derived from the server name. Mike used to have a server that identified as "Y" because, as he said, "Y is not X."
While the application itself is nameless (for it still is), the code repository did require a name of sorts. Mike named the repository "streams".
Now, the community needed something to call that nameless software when they spoke about it. So they unofficially established "(streams)", complete with parentheses that make sure that this is not actually the name of this software. Those who say, "Streams," with a capital S and no parentheses, and who use that term as if it's an official name, usually sincerely believe that this is the official name.
Mike himself uses "streams" without the parentheses because even he needs something to call his own software by. Before Forte was made, he preferred talking about the streams repository without directly mentioning the software. And he himself denied that (streams) is even a project. It's just a bunch of code that runs.
As far as I know, it was now possible to freely crossgrade between six different server applications because they were still identical in features. Only that Mike also had six server applications to take care of now.
So on December 31st, 2022, Mike discontinued Zap, Osada, Misty, Redmatrix and Roadhouse. Admins who ran either of these on their servers were recommended to rebase their servers to the streams repository. In this case, by the way, the old branding was kept. I've seen a server that still had "zap" as its subdomain which indicated that it was set up as a Zap server, that had Misty branding, but that actually ran (streams).
From then on, Mike dedicated his time to maintaining and developing only the streams repository. He still occasionally helped Hubzilla out, though.
In 2023, the Mitra creator and developer silverpill approached Mike. The goal was to make Mitra nomadic. I guess earlier attempts using a blockchain and crypto technology didn't come to fruition, so it had to be Mike's way which had proven itself stable for more than a decade. However, Mitra was to remain based on ActivityPub.
It was in this exchange that Mike realised that ActivityPub could indeed be used for nomadic identity if a few things were added to it. One outcome was FEP-ef61 "Portable Objects" which introduced decentralised IDs (DIDs) that would not be bound to any one server domain.
Instead of creating a whole new server application to play with, Mike simply made a "nomadic" branch in the streams repository (even though the software was already nomadic) in which he implemented support for nomadic identity via ActivityPub. Support as in (streams) understanding it while internally still using Nomad for nomadicity.
In June, 2024, Mike considered the "nomadic" branch reliable enough and merged it into the "dev" branch.
In July, 2024, Mike merged the "dev" branch into the "release" branch which caused DIDs as per FEP-ef61 to be rolled out to existing production servers. On accounts created on this new version, channels would have a DID internally. On accounts greated on any previous version, even new channels would keep the old ID system for the time being. This way, existing accounts and channels weren't messed with.
However, what had worked under supervised and restricted lab conditions completely blew up under real-life conditions. Again, I was there on (streams) with a pre-DID account and two channels on it. I still have them. (streams) channels wouldn't federate with anything anymore. It had become impossible to send anything anywhere. What Mike was facing was nothing short of an enigma because not even he knew what was going in.
So he started tinkering. In mid-August, Mike forked the streams repository into something named and branded Forte. He did so so he could rip the Nomad protocol out while still keeping the entire functionality. He had to get rid of Nomad because he had discovered that (streams) got confused juggling all the many IDs it had to deal with, so he had to weed out the Nomad and Zot6 IDs to make things easier. But he couldn't possibly have done that on (streams) proper.
This way, Mike created the very first Fediverse server software that uses ActivityPub for full nomadicity, including cloning.
By the end of August, things got back to normal. But Mike, having spent every free minute in the last few weeks to get (streams) back into working condition, was burned out. He sent an open message around in which he declared that he would completely retire from Fediverse development, and both the streams repository and Forte were up for grabs.
But nobody was found who could take over either. (streams) and Forte probably had way fewer than 100 users combined. Those few who would have been able to maintain either didn't have time. One did have time and was willing to do so, but he didn't know how to code. He eventually did start teaching himself, and he occasionally contributes merge requests, but there was no way he could take over as the only dev for either, much less both. So Mike had to go on, whether he wanted or not, albeit at a somewhat slower pace.
This is why Mike is still developing (streams) and Forte to this day.
By the way: The reason why Mike "abandoned" his old software was because he needed to invest all his time into protocol development and advancement. Mike isn't the one to constantly maintain stable server software unless he absolutely has to.
In 2011, he handed Friendica over to two new developers so that he had time to create the Zot protocol.
In 2015 already, he handed Hubzilla over to two new developers so that he had time to explore the advancement of the Zot protocol. He still contributed to Hubzilla's development.
In 2019, he wanted to hand Osada and Zap over to the community, now that they were stable, so he had time to develop Zot8. But the Osada/Zap community was so tiny that he couldn't get a new dedicated developer team together.
In 2024, he wanted to hand (streams) and Forte over to the community because fixing (streams)' huge identity bug, which led to Forte's creation, had burnt him out. He wanted to quit. But, again, he couldn't because (streams) didn't have a single user who had both the time and the knowledge to take over as the new main dev.
Consider this: Gargron was a young man when he made Mastodon. I think he was still at university. Mike Macgirvin made Friendica, he had some three decades of professional work in IT and software under his belly. Gargron was at the beginning of his career. Mike had quit and moved from the USA to the western Australian outback where he has been living as a farmer ever since. He might actually be older than Gargron's parents.while nomadic identitity would be cool thing, currently it does not exist
Take off your Mastodon glasses and look at the Fediverse and what it actually is like.
Nomadic identity does exist. Not as a vague idea, not as a concept on paper, but as a stable, production-grade feature that has been used to its full extent for well over a decade now. Just because Mastodon doesn't have it, doesn't mean the Fediverse doesn't have it. And just because Mastodon doesn't recognise it, doesn't mean it doesn't exist.
The Fediverse has loads of features which Mastodon users want "the Fediverse" to have. It has features which many Mastodon users have never wanted "the Fediverse" to have such as quote-posts, introduced by Mike Macgirvin on Mistpark in 2010. It even has features that are completely and utterly unimaginable for Mastodon users, and it has had even these since as early as 2010, 2012 or 2015.
Nomadic identity was invented by Mike Macgirvin in 2011 with the Zot protocol.
It was first implemented by him in mid-2012 when he rewrote Red against Zot. This means that Hubzilla itself has been offering full-blown nomadic identity since 2012, almost four years longer than Mastodon has existed.
This very Hubzilla channel that I'm commenting from right here, right now, is actually nomadic. It is cloned across two servers: hub.netzgemeinde.eu and hub.hubzilla.de. And it has been since before Elon Musk announced to take over Twitter in early 2022. When I sent you this comment, it was automatically sync'd over to hub.hubzilla.de. When you sent the comment that I'm replying to, it was automatically sync'd over to hub.hubzilla.de. The clone has actually been of great help at least once.
Unfortunately, non-nomadic software identifies cloned channels as fully separate accounts with fully separate identities. But rest assured: @Jupiter Rowland on hub.hubzilla.de is my clone. It's the live, hot, real-time, bidirectional backup of the main instance of my channel, @Jupiter Rowland on hub.netzgemeinde.eu that you're following now. They're both one and the same channel with one and the same identity,[email protected], even though Mastodon is unable to see it as such. Go check both. You'll see they've got all the same content in them, including comments from others. Including your comment. How else can[email protected]possibly have one of your comments under a post if you've only sent that comment to[email protected]if it weren't for nomadic identity?
Even nomadic identity via ActivityPub is available as a stable, production-grade feature in stable, production-grade software right now as we speak. Forte was the first to be fully nomadic via nothing but ActivityPub, as of mid-August, 2024. Tootik, based on Gemini instead of the World Wide Web, is fully nomadic at server level, too. Mitra is fully nomadic by means of the Minimitra client.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentricity #MastodonNormativity #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #ActivityPub #Zot #Zot6 #Zot8 #Nomad #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Mistpark #Mistpark2020 #Misty #Redmatrix2020 #Roadhouse #Streams #(streams) #Forte #Tootik #Mitra #Minimitra #NomadicIdentity -
@Chao-c'Also, ALT text translates with the rest of the post, which can be helpful for images which contain only foreign language text.
Hubzilla is the most incompatible ActivityPub software in Fediverse. You do just lot of things wrong, to put it mildly.
You still seem to think that Gargron invented ActivityPub and the Fediverse, that Mastodon is the one and only reference implementation of ActivityPub, and that everything that doesn't work exactly like Mastodon is broken.
Here are the facts:
Mastodon was launched in January, 2016.
Hubzilla was launched in March, 2015. Counting an earlier incarnation named Red, it was created in May, 2012, when Friendica's creator re-wrote his own fork of a Friendica fork of his own.
Mastodon implemented ActivityPub in September, 2017, when the spec wasn't finalised yet.
Hubzilla implemented ActivityPub in July, 2017. Two months before Mastodon. Hubzilla was the first software to ever implement ActivityPub.
Hubzilla implemented ActivityPub strictly by the book. It has always tried to stick as close to the official W3C ActivityPub spec as possible.
Mastodon, in stark contrast, has always been stretching the ActivityPub spec until it broke. Not only that, but it has always been adding stuff outside the spec. First it did so to take over certain features from StatusNet which was its original protocol. More recently, it did so with the very intention to break compatibility with the rest of the Fediverse and make everything that isn't Mastodon look broken. And people like you keep falling for it because they think they know for a fact that Mastodon is the ActivityPub reference implementation.
The whole Fediverse has to break the ActivityPub spec just to be able to federate with Mastodon.yes, the Hubzilla author is writing Streams, with nomadic identity, but it also means, that he understands, that Hubzilla approach is kind of dead-end.
You know nothing. Whereas I can rattle down the whole history from Mistpark in 2010 to today.
Mike Macgirvin, creator of Friendica, Hubzilla, (streams) and Forte created his post-Hubzilla server applications because he kept advancing the Zot protocol. And he couldn't implement these advancements into Hubzilla because they bore the chance of breaking compatibility with what already existed.
(streams) is not a completely new development, nor is it a straight Hubzilla fork.
(streams) is a 2022 fork of Roadhouse.
Which was a 2022 fork of either the third Osada or Mistpark 2020 or Redmatrix 2020.
Which were 2020 forks of Zap (or each other, but at least one of them was forked from Zap).
Which was a 2018 fork of either Hubzilla itself or the first Osada, which was a 2018 fork of Hubzilla.
Osada and Zap were created to develop Zot6. In its early stages of concept, Mike expected Zot6 to be incompatible with everything else. Mind you, he didn't see that as something bad. Advancing Zot was necessary because the then-current version of Zot was less than optimal. And Mike's vision was a decentralised, nomadic network named the "Grid", entirely based on Zot. The Grid would have been vastly superior to the existing Fediverse in every way possible.
So the issue with his early draft of Zot6 was that it was quite incompatible with non-nomadic protocols. Nomadic Zot6 content could not be translated into non-nomadic protocols like the diaspora* protocol or ActivityPub.
Thus, developing Zot6 on Hubzilla was out of question. Zot6 would have broken too much on Hubzilla. Besides, Hubzilla was bad as a platform to experiment on due to its wealth of supported protocols and other features, all of which would have had to be made compatible with Zot6.
And this is the real reason why Mike created Osada and Zap. From how I see it, and how I remember what he talked about back in the day (I was there, yes), he first forked Osada from Hubzilla. Then he ripped everything out that he didn't need, including support for all protocols except for Zot itself, ActivityPub, RSS and Atom, including the CMS stuff like articles, planning cards, notes, wikis and webpages, etc. Then he modified what was left against his early version of Zot6.
Then he discovered that a cloned Osada channel couldn't properly send content via ActivityPub.
Then, shortly afterwards, he forked Osada into Zap. He removed nomadic identity from Osada which kept ActivityPub and ActivityPub support from Zap which stayed nomadic.
The idea was to have a nomadic, cloned channel on Zap as your main channel that would only connect to Hubzilla, Osada and Zap, and to have an additional, non-nomadic channel on Osada that would serve as a "gateway" between nomadic Zap and the non-nomadic ActivityPub Fediverse.
Of course, this was highly impractical. But by 2019, Mike found a way to make Zot6 compatible with non-nomadic protocols. So, in early 2019, Mike discontinued Osada and forked a new Osada from Zap which only differred from Zap by having ActivityPub support while still being nomadic. This enabled Mike to have one development platform for Zot6 in conjunction with non-nomadic protocols and another one on which ActivityPub did not stand in the way.
Later in 2019, both Osada and Zap got stable releases. At that point, Osada and Zap were identical in code. Both had ActivityPub support. It was included into their cores now and no longer an add-on like on Hubzilla. They only had two differences. One was the branding. The other one was that Osada servers had ActivityPub activated by default, and Zap servers had ActivityPub disabled by default. Keeping Osada around was unnecessary now, so ActivityPub was activated by default on Zap, and Osada was discontinued. Zot6 was so stable that it was soon backported to Hubzilla.
Mike wasn't done yet, though. He now wanted to develop Zot8. Again, he did not want to develop protocol changes on stable production software that people potentially daily-drove.
Thus, three new forks emerged in 2020: another Osada, Mistpark 2020 (a.k.a. Misty) and Redmatrix 2020 (named after the Red Matrix, the name that Hubzilla bore from late 2012 to early 2015 between being created as Red and being re-branded into Hubzilla). Mike used them to develop Zot8. They were identical in all but brand identity.
This was fully intentional on Mike's part to confuse the hell out of the brand fetishists that were growing more and more numerous in the Fediverse. His goal was for people to declare Osada or Misty or Redmatrix the best Fediverse software and superior to everything else, just for him to tell them that Osada, Misty and Redmatrix are absolutely identical. In fact, the three remained identical to Zap in features.
Zot8 never got stable because Mike kept advancing it further and further. In early 2022, he was at Zot11. But Zot11 was so incompatible with everything else, including previous Zot versions, that Mike declared it a new protocol of its own and renamed it Nomad. In order to test-drive it, he forked Osada or Misty or Redmatrix into Roadhouse. After all, there were people who were daring enough to daily-drive production channels on Osada, Misty and Redmatrix, albeit only few. Roadhouse was still identical in features to Zap, Osada, Misty and Redmatrix.
It was now possible to crossgrade between Zap, Osada, Misty, Redmatrix and Roadhouse by simply rebasing the server code.
Later in 2022, he created a new fork of Roadhouse itself. The reason for this was not further protocol advancement. No, this time, it mostly had branding and licensing reasons.
First of all, he wanted to make that fork as easy for others to fork and adopt as possible. Everything he had developed so far was under the MIT license (he himself had relicensed Friendica under the AGPLv3 in 2011, but he didn't actually develop on Friendica; he developed on a fork named Free-Friendika that was still MIT-licensed and then backported the changes to the Friendica repository, and Red was a Free-Friendika fork). This new repository was released into the public domain. At first, the whole thing was never primarily intended to be installed on servers as it was, but rather to be forked as the base of something new.
At least the core and Mike's own add-ons were. What third-party add-ons from Hubzilla times were still there got to keep their maze of licenses. This was intentional on Mike's part, too. It would make it impossible for commercial players to scoop up the whole thing and relicense it into something non-free and commercial without breaking any licenses, or without pumping tons of money into their legal department to work around that maze of licenses.
Also, Mike removed any and all naming and branding from the software. He absolutely intentionally made it nameless. You've read that right. He did this for two reasons. One, whoever wanted to fork it would have to give the fork an individual name and an individual branding. Two, this was to mess with brand fanbois and brand fetishists even more: This thing had no brand to gush over to begin with.
Furthermore, Mike removed all nodeinfo code that he could possibly get away with removing. Again, this was intentional. One intention was to stop this software from automatically joining the "my Fediverse project is bigger than yours" and "my server is bigger than yours" rat races. He intentionally did everything he could to keep this software away from The Federation, Fediverse Observer, FediDB and the like.
The other intention was for the case of commercial players looking for free code to steal. If this software had really taken off and left its stats proving its popularity everywhere, some big commercial player would have been likely to try and steal this software, make it commercial and non-free and release it as their own original creation. So his intention was for them to not even be able to find it in this case. (This, by the way, was the reason why he relicensed Friendica under the AGPLv3, and why he hardly ever spoke about Free-Friendika: Now that Friendica was growing popular, he didn't want big commercial players to scoop up code of his under a license that they could change to non-free.)
This server application became the first and only one in the Fediverse with no fixed server type identifier, in fact, with none at all by default. It has one text field for the server name, just like Mastodon and Friendica and Hubzilla and the like. But it has an additional field where the server type, i.e. the identifier for the software, can be entered. If none is entered, it's derived from the server name. Mike used to have a server that identified as "Y" because, as he said, "Y is not X."
While the application itself is nameless (for it still is), the code repository did require a name of sorts. Mike named the repository "streams".
Now, the community needed something to call that nameless software when they spoke about it. So they unofficially established "(streams)", complete with parentheses that make sure that this is not actually the name of this software. Those who say, "Streams," with a capital S and no parentheses, and who use that term as if it's an official name, usually sincerely believe that this is the official name.
Mike himself uses "streams" without the parentheses because even he needs something to call his own software by. Before Forte was made, he preferred talking about the streams repository without directly mentioning the software. And he himself denied that (streams) is even a project. It's just a bunch of code that runs.
As far as I know, it was now possible to freely crossgrade between six different server applications because they were still identical in features. Only that Mike also had six server applications to take care of now.
So on December 31st, 2022, Mike discontinued Zap, Osada, Misty, Redmatrix and Roadhouse. Admins who ran either of these on their servers were recommended to rebase their servers to the streams repository. In this case, by the way, the old branding was kept. I've seen a server that still had "zap" as its subdomain which indicated that it was set up as a Zap server, that had Misty branding, but that actually ran (streams).
From then on, Mike dedicated his time to maintaining and developing only the streams repository. He still occasionally helped Hubzilla out, though.
In 2023, the Mitra creator and developer silverpill approached Mike. The goal was to make Mitra nomadic. I guess earlier attempts using a blockchain and crypto technology didn't come to fruition, so it had to be Mike's way which had proven itself stable for more than a decade. However, Mitra was to remain based on ActivityPub.
It was in this exchange that Mike realised that ActivityPub could indeed be used for nomadic identity if a few things were added to it. One outcome was FEP-ef61 "Portable Objects" which introduced decentralised IDs (DIDs) that would not be bound to any one server domain.
Instead of creating a whole new server application to play with, Mike simply made a "nomadic" branch in the streams repository (even though the software was already nomadic) in which he implemented support for nomadic identity via ActivityPub. Support as in (streams) understanding it while internally still using Nomad for nomadicity.
In June, 2024, Mike considered the "nomadic" branch reliable enough and merged it into the "dev" branch.
In July, 2024, Mike merged the "dev" branch into the "release" branch which caused DIDs as per FEP-ef61 to be rolled out to existing production servers. On accounts created on this new version, channels would have a DID internally. On accounts greated on any previous version, even new channels would keep the old ID system for the time being. This way, existing accounts and channels weren't messed with.
However, what had worked under supervised and restricted lab conditions completely blew up under real-life conditions. Again, I was there on (streams) with a pre-DID account and two channels on it. I still have them. (streams) channels wouldn't federate with anything anymore. It had become impossible to send anything anywhere. What Mike was facing was nothing short of an enigma because not even he knew what was going in.
So he started tinkering. In mid-August, Mike forked the streams repository into something named and branded Forte. He did so so he could rip the Nomad protocol out while still keeping the entire functionality. He had to get rid of Nomad because he had discovered that (streams) got confused juggling all the many IDs it had to deal with, so he had to weed out the Nomad and Zot6 IDs to make things easier. But he couldn't possibly have done that on (streams) proper.
This way, Mike created the very first Fediverse server software that uses ActivityPub for full nomadicity, including cloning.
By the end of August, things got back to normal. But Mike, having spent every free minute in the last few weeks to get (streams) back into working condition, was burned out. He sent an open message around in which he declared that he would completely retire from Fediverse development, and both the streams repository and Forte were up for grabs.
But nobody was found who could take over either. (streams) and Forte probably had way fewer than 100 users combined. Those few who would have been able to maintain either didn't have time. One did have time and was willing to do so, but he didn't know how to code. He eventually did start teaching himself, and he occasionally contributes merge requests, but there was no way he could take over as the only dev for either, much less both. So Mike had to go on, whether he wanted or not, albeit at a somewhat slower pace.
This is why Mike is still developing (streams) and Forte to this day.
By the way: The reason why Mike "abandoned" his old software was because he needed to invest all his time into protocol development and advancement. Mike isn't the one to constantly maintain stable server software unless he absolutely has to.
In 2011, he handed Friendica over to two new developers so that he had time to create the Zot protocol.
In 2015 already, he handed Hubzilla over to two new developers so that he had time to explore the advancement of the Zot protocol. He still contributed to Hubzilla's development.
In 2019, he wanted to hand Osada and Zap over to the community, now that they were stable, so he had time to develop Zot8. But the Osada/Zap community was so tiny that he couldn't get a new dedicated developer team together.
In 2024, he wanted to hand (streams) and Forte over to the community because fixing (streams)' huge identity bug, which led to Forte's creation, had burnt him out. He wanted to quit. But, again, he couldn't because (streams) didn't have a single user who had both the time and the knowledge to take over as the new main dev.
Consider this: Gargron was a young man when he made Mastodon. I think he was still at university. Mike Macgirvin made Friendica, he had some three decades of professional work in IT and software under his belly. Gargron was at the beginning of his career. Mike had quit and moved from the USA to the western Australian outback where he has been living as a farmer ever since. He might actually be older than Gargron's parents.while nomadic identitity would be cool thing, currently it does not exist
Take off your Mastodon glasses and look at the Fediverse and what it actually is like.
Nomadic identity does exist. Not as a vague idea, not as a concept on paper, but as a stable, production-grade feature that has been used to its full extent for well over a decade now. Just because Mastodon doesn't have it, doesn't mean the Fediverse doesn't have it. And just because Mastodon doesn't recognise it, doesn't mean it doesn't exist.
The Fediverse has loads of features which Mastodon users want "the Fediverse" to have. It has features which many Mastodon users have never wanted "the Fediverse" to have such as quote-posts, introduced by Mike Macgirvin on Mistpark in 2010. It even has features that are completely and utterly unimaginable for Mastodon users, and it has had even these since as early as 2010, 2012 or 2015.
Nomadic identity was invented by Mike Macgirvin in 2011 with the Zot protocol.
It was first implemented by him in mid-2012 when he rewrote Red against Zot. This means that Hubzilla itself has been offering full-blown nomadic identity since 2012, almost four years longer than Mastodon has existed.
This very Hubzilla channel that I'm commenting from right here, right now, is actually nomadic. It is cloned across two servers: hub.netzgemeinde.eu and hub.hubzilla.de. And it has been since before Elon Musk announced to take over Twitter in early 2022. When I sent you this comment, it was automatically sync'd over to hub.hubzilla.de. When you sent the comment that I'm replying to, it was automatically sync'd over to hub.hubzilla.de. The clone has actually been of great help at least once.
Unfortunately, non-nomadic software identifies cloned channels as fully separate accounts with fully separate identities. But rest assured: @Jupiter Rowland on hub.hubzilla.de is my clone. It's the live, hot, real-time, bidirectional backup of the main instance of my channel, @Jupiter Rowland on hub.netzgemeinde.eu that you're following now. They're both one and the same channel with one and the same identity,[email protected], even though Mastodon is unable to see it as such. Go check both. You'll see they've got all the same content in them, including comments from others. Including your comment. How else can[email protected]possibly have one of your comments under a post if you've only sent that comment to[email protected]if it weren't for nomadic identity?
Even nomadic identity via ActivityPub is available as a stable, production-grade feature in stable, production-grade software right now as we speak. Forte was the first to be fully nomadic via nothing but ActivityPub, as of mid-August, 2024. Tootik, based on Gemini instead of the World Wide Web, is fully nomadic at server level, too. Mitra is fully nomadic by means of the Minimitra client.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentricity #MastodonNormativity #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #ActivityPub #Zot #Zot6 #Zot8 #Nomad #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Mistpark #Mistpark2020 #Misty #Redmatrix2020 #Roadhouse #Streams #(streams) #Forte #Tootik #Mitra #Minimitra #NomadicIdentity -
@Truth & Answers Let me be honest: Mastodon isn't the right thing to rely on for this.
There are two common misconceptions on Mastodon about Mastodon. The first one is that Mastodon is the only free, non-commercial, non-corporate, decentralised social anything. Once Mastodon users are over this, they still think Mastodon is the best free, non-commercial, non-corporate, decentralised social anything.
I've seen Mastodon being advertised by users as a Fediverse alternative to literally everything, including Reddit (because, like, you can communicate, right?) and even YouTube (because, like, you can upload videos, right?).
But again, let me be honest: The only thing that Mastodon can hope to be an alternative to is 𝕏. Because it's a Twitter clone. A purist Twitter clone whose developers intentionally reject feature requests because the requested features don't fit into their image of purist, minimalist, old-school, original-gangsta microblogging. They want to keep Mastodon a slightly more glorified SMS than 𝕏.
Mastodon isn't even the only microblogging server application in the Fediverse. It isn't even the best at that. 80-90% of Mastodon's users don't and probably will never realise that Mastodon is an intentionally crippled resource hog. Many believe that Mastodon is the fully-featured be-all, end-all of social networking.
By the way, even the Mastodon developers claim that Mastodon is fully featured. I've had a Mastodon dev try hard to convince me that Mastodon is fully featured although I've told him that I'm on Hubzilla. He essentially tried to tell me that Mastodon has every last feature that Hubzilla has plus even more on top.
In reality, Mastodon isn't the fully-featured be-all, end-all of social networking. It isn't even a social network. It's social media, just like 𝕏 is social media. It's designed for pumping out content and being followed because it's designed as a Twitter-like microblogging application. And it isn't even the best at microblogging.
Almost everyone on Mastodon is fully convinced that Mastodon has to be the best. After all, it's the biggest. It's what everyone chose.
No.
Mastodon is the biggest because everyone who wants to leave 𝕏 or Threads or Bluesky is railroaded to Mastodon. It's the biggest because all the newbies are only told about Mastodon. It's the biggest because none of the newbies even learn upon on-boarding that other 𝕏 alternatives exist in the Fediverse, that anything else exists in the Fediverse other than Mastodon. It's the biggest because mainstream media, tech media and even Fediverse activists only ever talk about Mastodon, Mastodon, Mastodon. (Granted, it's also the biggest because it's the only one with an official phone app in the Apple App Store and the Google Play Store. Even though that app sucks.)
All these Mastodon users who claim that Mastodon is the best choice don't realise that they themselves did, in fact, not choose Mastodon. They didn't know they had a choice. All they were told about was Mastodon. Seriously, if they'd had a choice, they'd probably be on Sharkey now and not on Mastodon.
I've read what people had to say who moved from Friendica to Misskey. Or to now defunct Calckey/Firefish. Or to Sharkey. Or to Akkoma. All these are microblogging server applications in the Fediverse. But none of them are intentionally crippled to stay close to Twitter, at least not to such a degree as Mastodon.
It was nothing short of eye-opening to them. Only by daily-driving something else than Mastodon did they realise what the non-Mastodon Fediverse can be like. And how crippled Mastodon actually is. That Mastodon is far from being the absolute pinnacle in decentralised social media.
They no longer had only 500 characters. They had thousands of characters. They would have had thousands of characters on every server running that software without having to ask around which one has more than 500 characters. It felt like a restraint being removed which they had never considered a restraint, at least not that much of it.
They saw text formatting which they considered technologically absolutely impossible in the Fediverse when they were on Mastodon. In fact, they had considered text formatting entirely impossible while on Mastodon until they had come across the first message from outside with text formatting. Actual text formatting, not Unicode trickery. Now they suddenly saw a lot of the stuff that Mastodon's HTML sanitiser removes. And they themselves could use it!
If they were on one of the *keys, they no longer had a timeline of single-message piecemeal. For the first time ever, they experienced what it's like to have something else than single-message piecemeal. Namely entire conversations right in front of them, right away. Without having to dig for them first.
They had features which they had always wished the Fediverse may introduce. They never knew that the Fediverse does have these features, only Mastodon doesn't. They had features that were completely unimagiable to them in the Fediverse.
There are users who have moved from Mastodon to something "minimalist" and lightweight like snac or GoToSocial, often on self-hosted, single-user, private servers. Even they suddenly had features they didn't have on Mastodon. Mind you, while not missing a single Mastodon feature (except maybe for a built-in Web UI).
And that's just the microblogging side of the Fediverse. None of this is actual social networking. You know, what Facebook does.
First of all, if it's about following and being followed, it's social media. A social network doesn't have followers. In case you don't know, Facebook doesn't have followers. It has "friends". Bidirectional connections. Not 𝕏/Mastodon-like mutuals which are two connections, one in each direction, but one connection that goes both ways.
Besides, there are even more important social networking features missing from the microblogging side of the Fediverse.
Where are the contact suggestions? Where does Mastodon suggest new contacts based on how many contacts you have in common with them? Where does Mastodon suggest new contacts based on what profile information you have in common with them?
Oh, right, the latter is impossible because Mastodon doesn't have profile fields with defined purposes. In fact, where are these? Every good social network has them! But Mastodon only gives you four all-purpose profile fields (just like Mastodon only gives you four of everything, four file attachments, four options in polls...).
Where is the list of unread posts, unread comments and other unnoticed actions? How are you to make sure you really catch everything your friends do? Because you can't do that if all you have is a timeline to scroll through until you no longer see new stuff. If you manage to scroll down that far. And only absolute newbies can do that on Mastodon because they hardly follow anyone.
Where are groups? Seriously, I've lost count of how many times Mastodon users said "the Fediverse" must introduce something like Facebook Groups. The huge majority of Mastodon users is fully convinced that the Fediverse does not have groups in any shape or form because Mastodon doesn't have them.
Where are all these things? In the Fediverse, no less? Where are they?
I'll tell you where they are.
Friendica. Hubzilla. (streams). Forte.
The actual social networking side of the Fediverse (although Hubzilla is more like a social CMS or a "social Swiss army knife" that you can also use as a Facebook-like social networking application). I mean, I've already explained that Friendica was created in 2010 as a Facebook alternative. Not a faithful Facebook clone, though, but better than Facebook.
Mike Macgirvin took over from Facebook what social networks really need. And Farmville isn't that, and spying on your users and passing that data on to the NSA and selling it to the highest bidder isn't that, so he didn't take over that. He didn't want to build a clone that also adopts the bad sides just to be as close to the original as possible.
He took over the detailed profiles with profile fields with dedicated purposes. He took over profile privacy settings. In general, he took over a lot of privacy features. He took over advanced user discovery and connection suggestions. He took over bidirectional connections, only without that silly name "friends". He took over groups with moderation, only that a group on Friendica is just another account with a special automated reposter. He took over enclosed threaded conversations with one post at the top and otherwise only comments. He took over a "timeline" of full conversations as the default. He took over the event calendar. And so forth.
Instead, he added useful stuff on top. He gave Friendica all the posting features to make it fully capable of long-form blogging with all bells and whistles. No character limit (except for in the database, but I think that was over 65,000 back in the day already). All HTML text formatting features (only that Friendica only used BBcode back then; now it can optionally also use Markdown). A post/thread title. Summaries. Embedded images and other media with no limit in number. He even added a spoiler tag like in forums that can hide parts of a message.
He took care of privacy beyond what Facebook had to offer. He introduced a permissions system. Friendica got multiple profile per account, only one of which is public, so that you can show different sides of yourself to different connections.
Now, if you want to embed images or other media in your messages, you have to store them somewhere. And not everyone could be expected to set up a little file space somewhere. So he built a file space into Friendica, one that can even be used as a Dropbox alternative, all the way to restricted access to certain directories.
Mike also added a content warning system that automatically generates content warnings on the reader's side, based on a keyword list. If you need something behind content warnings, add the keywords to the list, and you'll have the respective content warnings, but the next user receiving the self-same post or comment does not have these content warnings if they don't need them.
One important part of what makes Friendica Friendica is being able to connect to a whole lot of stuff. For example, Friendica could federate with StatusNet via the OStatus protocol from the get-go; this is also how it immediately federated with Mastodon when the latter was launched. Mastodon generates an RSS feed, something that many users don't know. Friendica not only generates an Atom feed, but it can subscribe to feeds. Friendica can "federate" with e-mail. Over time, more and more connection features were added, including Tumblr, Twitter (!), Facebook (only for a few years before Facebook crippled it) and a WordPress cross-poster.
Lastly, he made it possible for third parties to add extra features by implementing an add-on system.
I dare those who are fully convinced that Mastodon is the best Facebook alternative possible to use Friendica for a year. Not only dip one toe in to the water, but use it as their one and only daily driver for everything they've used Mastodon for. Not scratching the surface and using it like Twitter while ignoring any and all features the Twitter they remember didn't have, but going all in. In fact, I dare those who are fully convinced that Mastodon is perfect and fully-featured to do the same.
And then there's Hubzilla. It came to exist by Mike forking Friendica in 2011, then forking that fork the same year, then rewriting that fork of a fork in 2012, then repurposing, rebranding, repositioning and greatly expanding it in 2015. Long story.
Hubzilla adds even more stuff on top. Most importantly, it introduced nomadic identity (https://joinfediverse.wiki/Nomadic_identity) in 2012.
Hubzilla, or its 2012 prototype form named Red, became the first decentralised social software that uncoupled the identity from the login. This was necessary for nomadic identity, but it also introduced the option to have multiple independent identities, basically what's an account elsewhere, on the same account, the same login. This makes sense, given the many different roles and purposes a Hubzilla channel can have. The big advantage over having multiple separate accounts is that you can switch between the channels on your account without logging out and back in.
Hubzilla, or its 2012 prototype form named Red, got an even more advanced and fine-grained permissions system. Hubzilla has 17 individual permissions on three levels, channel level, contact level, content level. At channel level, each one has seven or eight permission options to choose from, depending on whether or not it makes sense to give a permission to everyone on the Internet.
Mike added optional features to Hubzilla that were previously unseen on social anything, features that you'd rather expect from a CMS and maybe not even from that. Non-federating long-form articles. Planning cards that are based on these articles. Wikis that can be formatted with BBcode or Markdown. Webpages that can be formatted with BBcode, Markdown or HTML, that can include dynamic content from elsewhere on the channel, and that can add extra content to the channel pages.
Hubzilla can even act as groupware. It has a CalDAV calendar server; the event calendar can double as a crude UI for the CalDAV calendars. It has an optional CardDAV addressbook server. Its built-in file storage can be accessed via WebDAV, so you theoretically even have some cloud file space you can mount as a network drive. Rather recently, there was even a way found to tie Collabora Office into Hubzilla.
If you should ever read about Bonfire: Bonfire is Hubzilla ordered from Wish.com. Whatever Bonfire promises to have or to introduce has been available as a rock-solid stable feature on Hubzilla for over a decade. Bonfire only gets away with what it's trying to do because nobody knows Hubzilla.
I think it's safe to say that those who "chose" Mastodon didn't choose it over the rest of the Fediverse because it's better. They "chose" it because they didn't even know they have a choice.
As for your post, the technology for redeveloping socialising is there. And it certainly isn't Mastodon, and it never will be Mastodon. Mastodon can't be that due to its design philosophy, due to it being a Twitter clone, due to its own developers intentionally crippling it.
If you want to move on from 1-way interaction, you have to move on from 1-way connections. Move on from Twitter followers to Facebook friends.
You have to offer better options for the users than shouting into the void, attaching a bunch of hashtags and hoping that some of their followers or someone who is following one of the hashtags happens to be bothered to scroll down their timeline far enough.
You have to make sure that people don't miss content due to basic design and philosophy decisions. You have to make sure that people don't miss content because they simply never know that this content is there in the first place, because they can't scroll down far enough their timelines until they reach that content. You need something else than a timeline of single messages to scroll down with the user not having an idea just how far down that timeline goes. You have to tell the user how much unread content there is, what it is, where it is, and take the user directly to that unread content.
You have to stop presenting content to users as a long list of single posts and more single posts with only tiny details telling them that these posts are, in fact, part of a longer conversation which they don't see. Where they have to click or tap themselves through various UI pages to see that post in its context. Users must see the whole conversation Right. Off. The bat.
You need groups. Not kluged onto something that had no group support whatsoever two seconds earlier, not intentionally crippled, not crippled by the technology they're built upon, not intentionally re-invented to be incompatible with whatever already exists (and this is how Mastodon would do them). But fully functional, on an appropriate base, interoperable, user-moderated, optionally private, optionally hiding from directories.
If you want to go "social", you really have to go social. You have to go Facebook, not Twitter.
Users must find other users based on common interests. Or users living close to them. Or users with lots of contacts in common with them. Not by being on the same local/regional server of the same server about a certain topic. Not by searching for hashtags in the main profile text. But by examining specialised profile fields and the contacts.
Users must have such users suggested to them as new connections. Users must have such users at the top of their directory. This is how Facebook does it. And this is one thing that Facebook has always done right.
Again, Mastodon will never offer any of this. But that doesn't mean that you'll have to compromise and lower your expectations. Because you don't have to. There are server applications in the Fediverse, fully federated with Mastodon, that offer literally all of that. They exist right now. And some of them have existed for longer than Mastodon.
If you need something better than today's Mastodon, stop wishing for a better Mastodon. Instead, use something that's better and more appropriate for the job than Mastodon right now. For it exists right now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #500Characters #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #Fediverse #Mastodon #MastodonFediverse #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Friendica #Hubzilla #Streams #(streams) #Forte #Privacy #Permission #Permissions #Groups #FediverseGroups #FediGroups #NomadicIdentity #MastodonCentricity #MastodonNormativity -
@Truth & Answers Let me be honest: Mastodon isn't the right thing to rely on for this.
There are two common misconceptions on Mastodon about Mastodon. The first one is that Mastodon is the only free, non-commercial, non-corporate, decentralised social anything. Once Mastodon users are over this, they still think Mastodon is the best free, non-commercial, non-corporate, decentralised social anything.
I've seen Mastodon being advertised by users as a Fediverse alternative to literally everything, including Reddit (because, like, you can communicate, right?) and even YouTube (because, like, you can upload videos, right?).
But again, let me be honest: The only thing that Mastodon can hope to be an alternative to is 𝕏. Because it's a Twitter clone. A purist Twitter clone whose developers intentionally reject feature requests because the requested features don't fit into their image of purist, minimalist, old-school, original-gangsta microblogging. They want to keep Mastodon a slightly more glorified SMS than 𝕏.
Mastodon isn't even the only microblogging server application in the Fediverse. It isn't even the best at that. 80-90% of Mastodon's users don't and probably will never realise that Mastodon is an intentionally crippled resource hog. Many believe that Mastodon is the fully-featured be-all, end-all of social networking.
By the way, even the Mastodon developers claim that Mastodon is fully featured. I've had a Mastodon dev try hard to convince me that Mastodon is fully featured although I've told him that I'm on Hubzilla. He essentially tried to tell me that Mastodon has every last feature that Hubzilla has plus even more on top.
In reality, Mastodon isn't the fully-featured be-all, end-all of social networking. It isn't even a social network. It's social media, just like 𝕏 is social media. It's designed for pumping out content and being followed because it's designed as a Twitter-like microblogging application. And it isn't even the best at microblogging.
Almost everyone on Mastodon is fully convinced that Mastodon has to be the best. After all, it's the biggest. It's what everyone chose.
No.
Mastodon is the biggest because everyone who wants to leave 𝕏 or Threads or Bluesky is railroaded to Mastodon. It's the biggest because all the newbies are only told about Mastodon. It's the biggest because none of the newbies even learn upon on-boarding that other 𝕏 alternatives exist in the Fediverse, that anything else exists in the Fediverse other than Mastodon. It's the biggest because mainstream media, tech media and even Fediverse activists only ever talk about Mastodon, Mastodon, Mastodon. (Granted, it's also the biggest because it's the only one with an official phone app in the Apple App Store and the Google Play Store. Even though that app sucks.)
All these Mastodon users who claim that Mastodon is the best choice don't realise that they themselves did, in fact, not choose Mastodon. They didn't know they had a choice. All they were told about was Mastodon. Seriously, if they'd had a choice, they'd probably be on Sharkey now and not on Mastodon.
I've read what people had to say who moved from Friendica to Misskey. Or to now defunct Calckey/Firefish. Or to Sharkey. Or to Akkoma. All these are microblogging server applications in the Fediverse. But none of them are intentionally crippled to stay close to Twitter, at least not to such a degree as Mastodon.
It was nothing short of eye-opening to them. Only by daily-driving something else than Mastodon did they realise what the non-Mastodon Fediverse can be like. And how crippled Mastodon actually is. That Mastodon is far from being the absolute pinnacle in decentralised social media.
They no longer had only 500 characters. They had thousands of characters. They would have had thousands of characters on every server running that software without having to ask around which one has more than 500 characters. It felt like a restraint being removed which they had never considered a restraint, at least not that much of it.
They saw text formatting which they considered technologically absolutely impossible in the Fediverse when they were on Mastodon. In fact, they had considered text formatting entirely impossible while on Mastodon until they had come across the first message from outside with text formatting. Actual text formatting, not Unicode trickery. Now they suddenly saw a lot of the stuff that Mastodon's HTML sanitiser removes. And they themselves could use it!
If they were on one of the *keys, they no longer had a timeline of single-message piecemeal. For the first time ever, they experienced what it's like to have something else than single-message piecemeal. Namely entire conversations right in front of them, right away. Without having to dig for them first.
They had features which they had always wished the Fediverse may introduce. They never knew that the Fediverse does have these features, only Mastodon doesn't. They had features that were completely unimagiable to them in the Fediverse.
There are users who have moved from Mastodon to something "minimalist" and lightweight like snac or GoToSocial, often on self-hosted, single-user, private servers. Even they suddenly had features they didn't have on Mastodon. Mind you, while not missing a single Mastodon feature (except maybe for a built-in Web UI).
And that's just the microblogging side of the Fediverse. None of this is actual social networking. You know, what Facebook does.
First of all, if it's about following and being followed, it's social media. A social network doesn't have followers. In case you don't know, Facebook doesn't have followers. It has "friends". Bidirectional connections. Not 𝕏/Mastodon-like mutuals which are two connections, one in each direction, but one connection that goes both ways.
Besides, there are even more important social networking features missing from the microblogging side of the Fediverse.
Where are the contact suggestions? Where does Mastodon suggest new contacts based on how many contacts you have in common with them? Where does Mastodon suggest new contacts based on what profile information you have in common with them?
Oh, right, the latter is impossible because Mastodon doesn't have profile fields with defined purposes. In fact, where are these? Every good social network has them! But Mastodon only gives you four all-purpose profile fields (just like Mastodon only gives you four of everything, four file attachments, four options in polls...).
Where is the list of unread posts, unread comments and other unnoticed actions? How are you to make sure you really catch everything your friends do? Because you can't do that if all you have is a timeline to scroll through until you no longer see new stuff. If you manage to scroll down that far. And only absolute newbies can do that on Mastodon because they hardly follow anyone.
Where are groups? Seriously, I've lost count of how many times Mastodon users said "the Fediverse" must introduce something like Facebook Groups. The huge majority of Mastodon users is fully convinced that the Fediverse does not have groups in any shape or form because Mastodon doesn't have them.
Where are all these things? In the Fediverse, no less? Where are they?
I'll tell you where they are.
Friendica. Hubzilla. (streams). Forte.
The actual social networking side of the Fediverse (although Hubzilla is more like a social CMS or a "social Swiss army knife" that you can also use as a Facebook-like social networking application). I mean, I've already explained that Friendica was created in 2010 as a Facebook alternative. Not a faithful Facebook clone, though, but better than Facebook.
Mike Macgirvin took over from Facebook what social networks really need. And Farmville isn't that, and spying on your users and passing that data on to the NSA and selling it to the highest bidder isn't that, so he didn't take over that. He didn't want to build a clone that also adopts the bad sides just to be as close to the original as possible.
He took over the detailed profiles with profile fields with dedicated purposes. He took over profile privacy settings. In general, he took over a lot of privacy features. He took over advanced user discovery and connection suggestions. He took over bidirectional connections, only without that silly name "friends". He took over groups with moderation, only that a group on Friendica is just another account with a special automated reposter. He took over enclosed threaded conversations with one post at the top and otherwise only comments. He took over a "timeline" of full conversations as the default. He took over the event calendar. And so forth.
Instead, he added useful stuff on top. He gave Friendica all the posting features to make it fully capable of long-form blogging with all bells and whistles. No character limit (except for in the database, but I think that was over 65,000 back in the day already). All HTML text formatting features (only that Friendica only used BBcode back then; now it can optionally also use Markdown). A post/thread title. Summaries. Embedded images and other media with no limit in number. He even added a spoiler tag like in forums that can hide parts of a message.
He took care of privacy beyond what Facebook had to offer. He introduced a permissions system. Friendica got multiple profile per account, only one of which is public, so that you can show different sides of yourself to different connections.
Now, if you want to embed images or other media in your messages, you have to store them somewhere. And not everyone could be expected to set up a little file space somewhere. So he built a file space into Friendica, one that can even be used as a Dropbox alternative, all the way to restricted access to certain directories.
Mike also added a content warning system that automatically generates content warnings on the reader's side, based on a keyword list. If you need something behind content warnings, add the keywords to the list, and you'll have the respective content warnings, but the next user receiving the self-same post or comment does not have these content warnings if they don't need them.
One important part of what makes Friendica Friendica is being able to connect to a whole lot of stuff. For example, Friendica could federate with StatusNet via the OStatus protocol from the get-go; this is also how it immediately federated with Mastodon when the latter was launched. Mastodon generates an RSS feed, something that many users don't know. Friendica not only generates an Atom feed, but it can subscribe to feeds. Friendica can "federate" with e-mail. Over time, more and more connection features were added, including Tumblr, Twitter (!), Facebook (only for a few years before Facebook crippled it) and a WordPress cross-poster.
Lastly, he made it possible for third parties to add extra features by implementing an add-on system.
I dare those who are fully convinced that Mastodon is the best Facebook alternative possible to use Friendica for a year. Not only dip one toe in to the water, but use it as their one and only daily driver for everything they've used Mastodon for. Not scratching the surface and using it like Twitter while ignoring any and all features the Twitter they remember didn't have, but going all in. In fact, I dare those who are fully convinced that Mastodon is perfect and fully-featured to do the same.
And then there's Hubzilla. It came to exist by Mike forking Friendica in 2011, then forking that fork the same year, then rewriting that fork of a fork in 2012, then repurposing, rebranding, repositioning and greatly expanding it in 2015. Long story.
Hubzilla adds even more stuff on top. Most importantly, it introduced nomadic identity (https://joinfediverse.wiki/Nomadic_identity) in 2012.
Hubzilla, or its 2012 prototype form named Red, became the first decentralised social software that uncoupled the identity from the login. This was necessary for nomadic identity, but it also introduced the option to have multiple independent identities, basically what's an account elsewhere, on the same account, the same login. This makes sense, given the many different roles and purposes a Hubzilla channel can have. The big advantage over having multiple separate accounts is that you can switch between the channels on your account without logging out and back in.
Hubzilla, or its 2012 prototype form named Red, got an even more advanced and fine-grained permissions system. Hubzilla has 17 individual permissions on three levels, channel level, contact level, content level. At channel level, each one has seven or eight permission options to choose from, depending on whether or not it makes sense to give a permission to everyone on the Internet.
Mike added optional features to Hubzilla that were previously unseen on social anything, features that you'd rather expect from a CMS and maybe not even from that. Non-federating long-form articles. Planning cards that are based on these articles. Wikis that can be formatted with BBcode or Markdown. Webpages that can be formatted with BBcode, Markdown or HTML, that can include dynamic content from elsewhere on the channel, and that can add extra content to the channel pages.
Hubzilla can even act as groupware. It has a CalDAV calendar server; the event calendar can double as a crude UI for the CalDAV calendars. It has an optional CardDAV addressbook server. Its built-in file storage can be accessed via WebDAV, so you theoretically even have some cloud file space you can mount as a network drive. Rather recently, there was even a way found to tie Collabora Office into Hubzilla.
If you should ever read about Bonfire: Bonfire is Hubzilla ordered from Wish.com. Whatever Bonfire promises to have or to introduce has been available as a rock-solid stable feature on Hubzilla for over a decade. Bonfire only gets away with what it's trying to do because nobody knows Hubzilla.
I think it's safe to say that those who "chose" Mastodon didn't choose it over the rest of the Fediverse because it's better. They "chose" it because they didn't even know they have a choice.
As for your post, the technology for redeveloping socialising is there. And it certainly isn't Mastodon, and it never will be Mastodon. Mastodon can't be that due to its design philosophy, due to it being a Twitter clone, due to its own developers intentionally crippling it.
If you want to move on from 1-way interaction, you have to move on from 1-way connections. Move on from Twitter followers to Facebook friends.
You have to offer better options for the users than shouting into the void, attaching a bunch of hashtags and hoping that some of their followers or someone who is following one of the hashtags happens to be bothered to scroll down their timeline far enough.
You have to make sure that people don't miss content due to basic design and philosophy decisions. You have to make sure that people don't miss content because they simply never know that this content is there in the first place, because they can't scroll down far enough their timelines until they reach that content. You need something else than a timeline of single messages to scroll down with the user not having an idea just how far down that timeline goes. You have to tell the user how much unread content there is, what it is, where it is, and take the user directly to that unread content.
You have to stop presenting content to users as a long list of single posts and more single posts with only tiny details telling them that these posts are, in fact, part of a longer conversation which they don't see. Where they have to click or tap themselves through various UI pages to see that post in its context. Users must see the whole conversation Right. Off. The bat.
You need groups. Not kluged onto something that had no group support whatsoever two seconds earlier, not intentionally crippled, not crippled by the technology they're built upon, not intentionally re-invented to be incompatible with whatever already exists (and this is how Mastodon would do them). But fully functional, on an appropriate base, interoperable, user-moderated, optionally private, optionally hiding from directories.
If you want to go "social", you really have to go social. You have to go Facebook, not Twitter.
Users must find other users based on common interests. Or users living close to them. Or users with lots of contacts in common with them. Not by being on the same local/regional server of the same server about a certain topic. Not by searching for hashtags in the main profile text. But by examining specialised profile fields and the contacts.
Users must have such users suggested to them as new connections. Users must have such users at the top of their directory. This is how Facebook does it. And this is one thing that Facebook has always done right.
Again, Mastodon will never offer any of this. But that doesn't mean that you'll have to compromise and lower your expectations. Because you don't have to. There are server applications in the Fediverse, fully federated with Mastodon, that offer literally all of that. They exist right now. And some of them have existed for longer than Mastodon.
If you need something better than today's Mastodon, stop wishing for a better Mastodon. Instead, use something that's better and more appropriate for the job than Mastodon right now. For it exists right now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #500Characters #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #Fediverse #Mastodon #MastodonFediverse #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Friendica #Hubzilla #Streams #(streams) #Forte #Privacy #Permission #Permissions #Groups #FediverseGroups #FediGroups #NomadicIdentity #MastodonCentricity #MastodonNormativity -
@Truth & Answers Let me be honest: Mastodon isn't the right thing to rely on for this.
There are two common misconceptions on Mastodon about Mastodon. The first one is that Mastodon is the only free, non-commercial, non-corporate, decentralised social anything. Once Mastodon users are over this, they still think Mastodon is the best free, non-commercial, non-corporate, decentralised social anything.
I've seen Mastodon being advertised by users as a Fediverse alternative to literally everything, including Reddit (because, like, you can communicate, right?) and even YouTube (because, like, you can upload videos, right?).
But again, let me be honest: The only thing that Mastodon can hope to be an alternative to is 𝕏. Because it's a Twitter clone. A purist Twitter clone whose developers intentionally reject feature requests because the requested features don't fit into their image of purist, minimalist, old-school, original-gangsta microblogging. They want to keep Mastodon a slightly more glorified SMS than 𝕏.
Mastodon isn't even the only microblogging server application in the Fediverse. It isn't even the best at that. 80-90% of Mastodon's users don't and probably will never realise that Mastodon is an intentionally crippled resource hog. Many believe that Mastodon is the fully-featured be-all, end-all of social networking.
By the way, even the Mastodon developers claim that Mastodon is fully featured. I've had a Mastodon dev try hard to convince me that Mastodon is fully featured although I've told him that I'm on Hubzilla. He essentially tried to tell me that Mastodon has every last feature that Hubzilla has plus even more on top.
In reality, Mastodon isn't the fully-featured be-all, end-all of social networking. It isn't even a social network. It's social media, just like 𝕏 is social media. It's designed for pumping out content and being followed because it's designed as a Twitter-like microblogging application. And it isn't even the best at microblogging.
Almost everyone on Mastodon is fully convinced that Mastodon has to be the best. After all, it's the biggest. It's what everyone chose.
No.
Mastodon is the biggest because everyone who wants to leave 𝕏 or Threads or Bluesky is railroaded to Mastodon. It's the biggest because all the newbies are only told about Mastodon. It's the biggest because none of the newbies even learn upon on-boarding that other 𝕏 alternatives exist in the Fediverse, that anything else exists in the Fediverse other than Mastodon. It's the biggest because mainstream media, tech media and even Fediverse activists only ever talk about Mastodon, Mastodon, Mastodon. (Granted, it's also the biggest because it's the only one with an official phone app in the Apple App Store and the Google Play Store. Even though that app sucks.)
All these Mastodon users who claim that Mastodon is the best choice don't realise that they themselves did, in fact, not choose Mastodon. They didn't know they had a choice. All they were told about was Mastodon. Seriously, if they'd had a choice, they'd probably be on Sharkey now and not on Mastodon.
I've read what people had to say who moved from Friendica to Misskey. Or to now defunct Calckey/Firefish. Or to Sharkey. Or to Akkoma. All these are microblogging server applications in the Fediverse. But none of them are intentionally crippled to stay close to Twitter, at least not to such a degree as Mastodon.
It was nothing short of eye-opening to them. Only by daily-driving something else than Mastodon did they realise what the non-Mastodon Fediverse can be like. And how crippled Mastodon actually is. That Mastodon is far from being the absolute pinnacle in decentralised social media.
They no longer had only 500 characters. They had thousands of characters. They would have had thousands of characters on every server running that software without having to ask around which one has more than 500 characters. It felt like a restraint being removed which they had never considered a restraint, at least not that much of it.
They saw text formatting which they considered technologically absolutely impossible in the Fediverse when they were on Mastodon. In fact, they had considered text formatting entirely impossible while on Mastodon until they had come across the first message from outside with text formatting. Actual text formatting, not Unicode trickery. Now they suddenly saw a lot of the stuff that Mastodon's HTML sanitiser removes. And they themselves could use it!
If they were on one of the *keys, they no longer had a timeline of single-message piecemeal. For the first time ever, they experienced what it's like to have something else than single-message piecemeal. Namely entire conversations right in front of them, right away. Without having to dig for them first.
They had features which they had always wished the Fediverse may introduce. They never knew that the Fediverse does have these features, only Mastodon doesn't. They had features that were completely unimagiable to them in the Fediverse.
There are users who have moved from Mastodon to something "minimalist" and lightweight like snac or GoToSocial, often on self-hosted, single-user, private servers. Even they suddenly had features they didn't have on Mastodon. Mind you, while not missing a single Mastodon feature (except maybe for a built-in Web UI).
And that's just the microblogging side of the Fediverse. None of this is actual social networking. You know, what Facebook does.
First of all, if it's about following and being followed, it's social media. A social network doesn't have followers. In case you don't know, Facebook doesn't have followers. It has "friends". Bidirectional connections. Not 𝕏/Mastodon-like mutuals which are two connections, one in each direction, but one connection that goes both ways.
Besides, there are even more important social networking features missing from the microblogging side of the Fediverse.
Where are the contact suggestions? Where does Mastodon suggest new contacts based on how many contacts you have in common with them? Where does Mastodon suggest new contacts based on what profile information you have in common with them?
Oh, right, the latter is impossible because Mastodon doesn't have profile fields with defined purposes. In fact, where are these? Every good social network has them! But Mastodon only gives you four all-purpose profile fields (just like Mastodon only gives you four of everything, four file attachments, four options in polls...).
Where is the list of unread posts, unread comments and other unnoticed actions? How are you to make sure you really catch everything your friends do? Because you can't do that if all you have is a timeline to scroll through until you no longer see new stuff. If you manage to scroll down that far. And only absolute newbies can do that on Mastodon because they hardly follow anyone.
Where are groups? Seriously, I've lost count of how many times Mastodon users said "the Fediverse" must introduce something like Facebook Groups. The huge majority of Mastodon users is fully convinced that the Fediverse does not have groups in any shape or form because Mastodon doesn't have them.
Where are all these things? In the Fediverse, no less? Where are they?
I'll tell you where they are.
Friendica. Hubzilla. (streams). Forte.
The actual social networking side of the Fediverse (although Hubzilla is more like a social CMS or a "social Swiss army knife" that you can also use as a Facebook-like social networking application). I mean, I've already explained that Friendica was created in 2010 as a Facebook alternative. Not a faithful Facebook clone, though, but better than Facebook.
Mike Macgirvin took over from Facebook what social networks really need. And Farmville isn't that, and spying on your users and passing that data on to the NSA and selling it to the highest bidder isn't that, so he didn't take over that. He didn't want to build a clone that also adopts the bad sides just to be as close to the original as possible.
He took over the detailed profiles with profile fields with dedicated purposes. He took over profile privacy settings. In general, he took over a lot of privacy features. He took over advanced user discovery and connection suggestions. He took over bidirectional connections, only without that silly name "friends". He took over groups with moderation, only that a group on Friendica is just another account with a special automated reposter. He took over enclosed threaded conversations with one post at the top and otherwise only comments. He took over a "timeline" of full conversations as the default. He took over the event calendar. And so forth.
Instead, he added useful stuff on top. He gave Friendica all the posting features to make it fully capable of long-form blogging with all bells and whistles. No character limit (except for in the database, but I think that was over 65,000 back in the day already). All HTML text formatting features (only that Friendica only used BBcode back then; now it can optionally also use Markdown). A post/thread title. Summaries. Embedded images and other media with no limit in number. He even added a spoiler tag like in forums that can hide parts of a message.
He took care of privacy beyond what Facebook had to offer. He introduced a permissions system. Friendica got multiple profile per account, only one of which is public, so that you can show different sides of yourself to different connections.
Now, if you want to embed images or other media in your messages, you have to store them somewhere. And not everyone could be expected to set up a little file space somewhere. So he built a file space into Friendica, one that can even be used as a Dropbox alternative, all the way to restricted access to certain directories.
Mike also added a content warning system that automatically generates content warnings on the reader's side, based on a keyword list. If you need something behind content warnings, add the keywords to the list, and you'll have the respective content warnings, but the next user receiving the self-same post or comment does not have these content warnings if they don't need them.
One important part of what makes Friendica Friendica is being able to connect to a whole lot of stuff. For example, Friendica could federate with StatusNet via the OStatus protocol from the get-go; this is also how it immediately federated with Mastodon when the latter was launched. Mastodon generates an RSS feed, something that many users don't know. Friendica not only generates an Atom feed, but it can subscribe to feeds. Friendica can "federate" with e-mail. Over time, more and more connection features were added, including Tumblr, Twitter (!), Facebook (only for a few years before Facebook crippled it) and a WordPress cross-poster.
Lastly, he made it possible for third parties to add extra features by implementing an add-on system.
I dare those who are fully convinced that Mastodon is the best Facebook alternative possible to use Friendica for a year. Not only dip one toe in to the water, but use it as their one and only daily driver for everything they've used Mastodon for. Not scratching the surface and using it like Twitter while ignoring any and all features the Twitter they remember didn't have, but going all in. In fact, I dare those who are fully convinced that Mastodon is perfect and fully-featured to do the same.
And then there's Hubzilla. It came to exist by Mike forking Friendica in 2011, then forking that fork the same year, then rewriting that fork of a fork in 2012, then repurposing, rebranding, repositioning and greatly expanding it in 2015. Long story.
Hubzilla adds even more stuff on top. Most importantly, it introduced nomadic identity (https://joinfediverse.wiki/Nomadic_identity) in 2012.
Hubzilla, or its 2012 prototype form named Red, became the first decentralised social software that uncoupled the identity from the login. This was necessary for nomadic identity, but it also introduced the option to have multiple independent identities, basically what's an account elsewhere, on the same account, the same login. This makes sense, given the many different roles and purposes a Hubzilla channel can have. The big advantage over having multiple separate accounts is that you can switch between the channels on your account without logging out and back in.
Hubzilla, or its 2012 prototype form named Red, got an even more advanced and fine-grained permissions system. Hubzilla has 17 individual permissions on three levels, channel level, contact level, content level. At channel level, each one has seven or eight permission options to choose from, depending on whether or not it makes sense to give a permission to everyone on the Internet.
Mike added optional features to Hubzilla that were previously unseen on social anything, features that you'd rather expect from a CMS and maybe not even from that. Non-federating long-form articles. Planning cards that are based on these articles. Wikis that can be formatted with BBcode or Markdown. Webpages that can be formatted with BBcode, Markdown or HTML, that can include dynamic content from elsewhere on the channel, and that can add extra content to the channel pages.
Hubzilla can even act as groupware. It has a CalDAV calendar server; the event calendar can double as a crude UI for the CalDAV calendars. It has an optional CardDAV addressbook server. Its built-in file storage can be accessed via WebDAV, so you theoretically even have some cloud file space you can mount as a network drive. Rather recently, there was even a way found to tie Collabora Office into Hubzilla.
If you should ever read about Bonfire: Bonfire is Hubzilla ordered from Wish.com. Whatever Bonfire promises to have or to introduce has been available as a rock-solid stable feature on Hubzilla for over a decade. Bonfire only gets away with what it's trying to do because nobody knows Hubzilla.
I think it's safe to say that those who "chose" Mastodon didn't choose it over the rest of the Fediverse because it's better. They "chose" it because they didn't even know they have a choice.
As for your post, the technology for redeveloping socialising is there. And it certainly isn't Mastodon, and it never will be Mastodon. Mastodon can't be that due to its design philosophy, due to it being a Twitter clone, due to its own developers intentionally crippling it.
If you want to move on from 1-way interaction, you have to move on from 1-way connections. Move on from Twitter followers to Facebook friends.
You have to offer better options for the users than shouting into the void, attaching a bunch of hashtags and hoping that some of their followers or someone who is following one of the hashtags happens to be bothered to scroll down their timeline far enough.
You have to make sure that people don't miss content due to basic design and philosophy decisions. You have to make sure that people don't miss content because they simply never know that this content is there in the first place, because they can't scroll down far enough their timelines until they reach that content. You need something else than a timeline of single messages to scroll down with the user not having an idea just how far down that timeline goes. You have to tell the user how much unread content there is, what it is, where it is, and take the user directly to that unread content.
You have to stop presenting content to users as a long list of single posts and more single posts with only tiny details telling them that these posts are, in fact, part of a longer conversation which they don't see. Where they have to click or tap themselves through various UI pages to see that post in its context. Users must see the whole conversation Right. Off. The bat.
You need groups. Not kluged onto something that had no group support whatsoever two seconds earlier, not intentionally crippled, not crippled by the technology they're built upon, not intentionally re-invented to be incompatible with whatever already exists (and this is how Mastodon would do them). But fully functional, on an appropriate base, interoperable, user-moderated, optionally private, optionally hiding from directories.
If you want to go "social", you really have to go social. You have to go Facebook, not Twitter.
Users must find other users based on common interests. Or users living close to them. Or users with lots of contacts in common with them. Not by being on the same local/regional server of the same server about a certain topic. Not by searching for hashtags in the main profile text. But by examining specialised profile fields and the contacts.
Users must have such users suggested to them as new connections. Users must have such users at the top of their directory. This is how Facebook does it. And this is one thing that Facebook has always done right.
Again, Mastodon will never offer any of this. But that doesn't mean that you'll have to compromise and lower your expectations. Because you don't have to. There are server applications in the Fediverse, fully federated with Mastodon, that offer literally all of that. They exist right now. And some of them have existed for longer than Mastodon.
If you need something better than today's Mastodon, stop wishing for a better Mastodon. Instead, use something that's better and more appropriate for the job than Mastodon right now. For it exists right now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #500Characters #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #Fediverse #Mastodon #MastodonFediverse #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Friendica #Hubzilla #Streams #(streams) #Forte #Privacy #Permission #Permissions #Groups #FediverseGroups #FediGroups #NomadicIdentity #MastodonCentricity #MastodonNormativity -
@Truth & Answers Let me be honest: Mastodon isn't the right thing to rely on for this.
There are two common misconceptions on Mastodon about Mastodon. The first one is that Mastodon is the only free, non-commercial, non-corporate, decentralised social anything. Once Mastodon users are over this, they still think Mastodon is the best free, non-commercial, non-corporate, decentralised social anything.
I've seen Mastodon being advertised by users as a Fediverse alternative to literally everything, including Reddit (because, like, you can communicate, right?) and even YouTube (because, like, you can upload videos, right?).
But again, let me be honest: The only thing that Mastodon can hope to be an alternative to is 𝕏. Because it's a Twitter clone. A purist Twitter clone whose developers intentionally reject feature requests because the requested features don't fit into their image of purist, minimalist, old-school, original-gangsta microblogging. They want to keep Mastodon a slightly more glorified SMS than 𝕏.
Mastodon isn't even the only microblogging server application in the Fediverse. It isn't even the best at that. 80-90% of Mastodon's users don't and probably will never realise that Mastodon is an intentionally crippled resource hog. Many believe that Mastodon is the fully-featured be-all, end-all of social networking.
By the way, even the Mastodon developers claim that Mastodon is fully featured. I've had a Mastodon dev try hard to convince me that Mastodon is fully featured although I've told him that I'm on Hubzilla. He essentially tried to tell me that Mastodon has every last feature that Hubzilla has plus even more on top.
In reality, Mastodon isn't the fully-featured be-all, end-all of social networking. It isn't even a social network. It's social media, just like 𝕏 is social media. It's designed for pumping out content and being followed because it's designed as a Twitter-like microblogging application. And it isn't even the best at microblogging.
Almost everyone on Mastodon is fully convinced that Mastodon has to be the best. After all, it's the biggest. It's what everyone chose.
No.
Mastodon is the biggest because everyone who wants to leave 𝕏 or Threads or Bluesky is railroaded to Mastodon. It's the biggest because all the newbies are only told about Mastodon. It's the biggest because none of the newbies even learn upon on-boarding that other 𝕏 alternatives exist in the Fediverse, that anything else exists in the Fediverse other than Mastodon. It's the biggest because mainstream media, tech media and even Fediverse activists only ever talk about Mastodon, Mastodon, Mastodon. (Granted, it's also the biggest because it's the only one with an official phone app in the Apple App Store and the Google Play Store. Even though that app sucks.)
All these Mastodon users who claim that Mastodon is the best choice don't realise that they themselves did, in fact, not choose Mastodon. They didn't know they had a choice. All they were told about was Mastodon. Seriously, if they'd had a choice, they'd probably be on Sharkey now and not on Mastodon.
I've read what people had to say who moved from Friendica to Misskey. Or to now defunct Calckey/Firefish. Or to Sharkey. Or to Akkoma. All these are microblogging server applications in the Fediverse. But none of them are intentionally crippled to stay close to Twitter, at least not to such a degree as Mastodon.
It was nothing short of eye-opening to them. Only by daily-driving something else than Mastodon did they realise what the non-Mastodon Fediverse can be like. And how crippled Mastodon actually is. That Mastodon is far from being the absolute pinnacle in decentralised social media.
They no longer had only 500 characters. They had thousands of characters. They would have had thousands of characters on every server running that software without having to ask around which one has more than 500 characters. It felt like a restraint being removed which they had never considered a restraint, at least not that much of it.
They saw text formatting which they considered technologically absolutely impossible in the Fediverse when they were on Mastodon. In fact, they had considered text formatting entirely impossible while on Mastodon until they had come across the first message from outside with text formatting. Actual text formatting, not Unicode trickery. Now they suddenly saw a lot of the stuff that Mastodon's HTML sanitiser removes. And they themselves could use it!
If they were on one of the *keys, they no longer had a timeline of single-message piecemeal. For the first time ever, they experienced what it's like to have something else than single-message piecemeal. Namely entire conversations right in front of them, right away. Without having to dig for them first.
They had features which they had always wished the Fediverse may introduce. They never knew that the Fediverse does have these features, only Mastodon doesn't. They had features that were completely unimagiable to them in the Fediverse.
There are users who have moved from Mastodon to something "minimalist" and lightweight like snac or GoToSocial, often on self-hosted, single-user, private servers. Even they suddenly had features they didn't have on Mastodon. Mind you, while not missing a single Mastodon feature (except maybe for a built-in Web UI).
And that's just the microblogging side of the Fediverse. None of this is actual social networking. You know, what Facebook does.
First of all, if it's about following and being followed, it's social media. A social network doesn't have followers. In case you don't know, Facebook doesn't have followers. It has "friends". Bidirectional connections. Not 𝕏/Mastodon-like mutuals which are two connections, one in each direction, but one connection that goes both ways.
Besides, there are even more important social networking features missing from the microblogging side of the Fediverse.
Where are the contact suggestions? Where does Mastodon suggest new contacts based on how many contacts you have in common with them? Where does Mastodon suggest new contacts based on what profile information you have in common with them?
Oh, right, the latter is impossible because Mastodon doesn't have profile fields with defined purposes. In fact, where are these? Every good social network has them! But Mastodon only gives you four all-purpose profile fields (just like Mastodon only gives you four of everything, four file attachments, four options in polls...).
Where is the list of unread posts, unread comments and other unnoticed actions? How are you to make sure you really catch everything your friends do? Because you can't do that if all you have is a timeline to scroll through until you no longer see new stuff. If you manage to scroll down that far. And only absolute newbies can do that on Mastodon because they hardly follow anyone.
Where are groups? Seriously, I've lost count of how many times Mastodon users said "the Fediverse" must introduce something like Facebook Groups. The huge majority of Mastodon users is fully convinced that the Fediverse does not have groups in any shape or form because Mastodon doesn't have them.
Where are all these things? In the Fediverse, no less? Where are they?
I'll tell you where they are.
Friendica. Hubzilla. (streams). Forte.
The actual social networking side of the Fediverse (although Hubzilla is more like a social CMS or a "social Swiss army knife" that you can also use as a Facebook-like social networking application). I mean, I've already explained that Friendica was created in 2010 as a Facebook alternative. Not a faithful Facebook clone, though, but better than Facebook.
Mike Macgirvin took over from Facebook what social networks really need. And Farmville isn't that, and spying on your users and passing that data on to the NSA and selling it to the highest bidder isn't that, so he didn't take over that. He didn't want to build a clone that also adopts the bad sides just to be as close to the original as possible.
He took over the detailed profiles with profile fields with dedicated purposes. He took over profile privacy settings. In general, he took over a lot of privacy features. He took over advanced user discovery and connection suggestions. He took over bidirectional connections, only without that silly name "friends". He took over groups with moderation, only that a group on Friendica is just another account with a special automated reposter. He took over enclosed threaded conversations with one post at the top and otherwise only comments. He took over a "timeline" of full conversations as the default. He took over the event calendar. And so forth.
Instead, he added useful stuff on top. He gave Friendica all the posting features to make it fully capable of long-form blogging with all bells and whistles. No character limit (except for in the database, but I think that was over 65,000 back in the day already). All HTML text formatting features (only that Friendica only used BBcode back then; now it can optionally also use Markdown). A post/thread title. Summaries. Embedded images and other media with no limit in number. He even added a spoiler tag like in forums that can hide parts of a message.
He took care of privacy beyond what Facebook had to offer. He introduced a permissions system. Friendica got multiple profile per account, only one of which is public, so that you can show different sides of yourself to different connections.
Now, if you want to embed images or other media in your messages, you have to store them somewhere. And not everyone could be expected to set up a little file space somewhere. So he built a file space into Friendica, one that can even be used as a Dropbox alternative, all the way to restricted access to certain directories.
Mike also added a content warning system that automatically generates content warnings on the reader's side, based on a keyword list. If you need something behind content warnings, add the keywords to the list, and you'll have the respective content warnings, but the next user receiving the self-same post or comment does not have these content warnings if they don't need them.
One important part of what makes Friendica Friendica is being able to connect to a whole lot of stuff. For example, Friendica could federate with StatusNet via the OStatus protocol from the get-go; this is also how it immediately federated with Mastodon when the latter was launched. Mastodon generates an RSS feed, something that many users don't know. Friendica not only generates an Atom feed, but it can subscribe to feeds. Friendica can "federate" with e-mail. Over time, more and more connection features were added, including Tumblr, Twitter (!), Facebook (only for a few years before Facebook crippled it) and a WordPress cross-poster.
Lastly, he made it possible for third parties to add extra features by implementing an add-on system.
I dare those who are fully convinced that Mastodon is the best Facebook alternative possible to use Friendica for a year. Not only dip one toe in to the water, but use it as their one and only daily driver for everything they've used Mastodon for. Not scratching the surface and using it like Twitter while ignoring any and all features the Twitter they remember didn't have, but going all in. In fact, I dare those who are fully convinced that Mastodon is perfect and fully-featured to do the same.
And then there's Hubzilla. It came to exist by Mike forking Friendica in 2011, then forking that fork the same year, then rewriting that fork of a fork in 2012, then repurposing, rebranding, repositioning and greatly expanding it in 2015. Long story.
Hubzilla adds even more stuff on top. Most importantly, it introduced nomadic identity (https://joinfediverse.wiki/Nomadic_identity) in 2012.
Hubzilla, or its 2012 prototype form named Red, became the first decentralised social software that uncoupled the identity from the login. This was necessary for nomadic identity, but it also introduced the option to have multiple independent identities, basically what's an account elsewhere, on the same account, the same login. This makes sense, given the many different roles and purposes a Hubzilla channel can have. The big advantage over having multiple separate accounts is that you can switch between the channels on your account without logging out and back in.
Hubzilla, or its 2012 prototype form named Red, got an even more advanced and fine-grained permissions system. Hubzilla has 17 individual permissions on three levels, channel level, contact level, content level. At channel level, each one has seven or eight permission options to choose from, depending on whether or not it makes sense to give a permission to everyone on the Internet.
Mike added optional features to Hubzilla that were previously unseen on social anything, features that you'd rather expect from a CMS and maybe not even from that. Non-federating long-form articles. Planning cards that are based on these articles. Wikis that can be formatted with BBcode or Markdown. Webpages that can be formatted with BBcode, Markdown or HTML, that can include dynamic content from elsewhere on the channel, and that can add extra content to the channel pages.
Hubzilla can even act as groupware. It has a CalDAV calendar server; the event calendar can double as a crude UI for the CalDAV calendars. It has an optional CardDAV addressbook server. Its built-in file storage can be accessed via WebDAV, so you theoretically even have some cloud file space you can mount as a network drive. Rather recently, there was even a way found to tie Collabora Office into Hubzilla.
If you should ever read about Bonfire: Bonfire is Hubzilla ordered from Wish.com. Whatever Bonfire promises to have or to introduce has been available as a rock-solid stable feature on Hubzilla for over a decade. Bonfire only gets away with what it's trying to do because nobody knows Hubzilla.
I think it's safe to say that those who "chose" Mastodon didn't choose it over the rest of the Fediverse because it's better. They "chose" it because they didn't even know they have a choice.
As for your post, the technology for redeveloping socialising is there. And it certainly isn't Mastodon, and it never will be Mastodon. Mastodon can't be that due to its design philosophy, due to it being a Twitter clone, due to its own developers intentionally crippling it.
If you want to move on from 1-way interaction, you have to move on from 1-way connections. Move on from Twitter followers to Facebook friends.
You have to offer better options for the users than shouting into the void, attaching a bunch of hashtags and hoping that some of their followers or someone who is following one of the hashtags happens to be bothered to scroll down their timeline far enough.
You have to make sure that people don't miss content due to basic design and philosophy decisions. You have to make sure that people don't miss content because they simply never know that this content is there in the first place, because they can't scroll down far enough their timelines until they reach that content. You need something else than a timeline of single messages to scroll down with the user not having an idea just how far down that timeline goes. You have to tell the user how much unread content there is, what it is, where it is, and take the user directly to that unread content.
You have to stop presenting content to users as a long list of single posts and more single posts with only tiny details telling them that these posts are, in fact, part of a longer conversation which they don't see. Where they have to click or tap themselves through various UI pages to see that post in its context. Users must see the whole conversation Right. Off. The bat.
You need groups. Not kluged onto something that had no group support whatsoever two seconds earlier, not intentionally crippled, not crippled by the technology they're built upon, not intentionally re-invented to be incompatible with whatever already exists (and this is how Mastodon would do them). But fully functional, on an appropriate base, interoperable, user-moderated, optionally private, optionally hiding from directories.
If you want to go "social", you really have to go social. You have to go Facebook, not Twitter.
Users must find other users based on common interests. Or users living close to them. Or users with lots of contacts in common with them. Not by being on the same local/regional server of the same server about a certain topic. Not by searching for hashtags in the main profile text. But by examining specialised profile fields and the contacts.
Users must have such users suggested to them as new connections. Users must have such users at the top of their directory. This is how Facebook does it. And this is one thing that Facebook has always done right.
Again, Mastodon will never offer any of this. But that doesn't mean that you'll have to compromise and lower your expectations. Because you don't have to. There are server applications in the Fediverse, fully federated with Mastodon, that offer literally all of that. They exist right now. And some of them have existed for longer than Mastodon.
If you need something better than today's Mastodon, stop wishing for a better Mastodon. Instead, use something that's better and more appropriate for the job than Mastodon right now. For it exists right now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #500Characters #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #Fediverse #Mastodon #MastodonFediverse #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Friendica #Hubzilla #Streams #(streams) #Forte #Privacy #Permission #Permissions #Groups #FediverseGroups #FediGroups #NomadicIdentity #MastodonCentricity #MastodonNormativity -
@Truth & Answers Let me be honest: Mastodon isn't the right thing to rely on for this.
There are two common misconceptions on Mastodon about Mastodon. The first one is that Mastodon is the only free, non-commercial, non-corporate, decentralised social anything. Once Mastodon users are over this, they still think Mastodon is the best free, non-commercial, non-corporate, decentralised social anything.
I've seen Mastodon being advertised by users as a Fediverse alternative to literally everything, including Reddit (because, like, you can communicate, right?) and even YouTube (because, like, you can upload videos, right?).
But again, let me be honest: The only thing that Mastodon can hope to be an alternative to is 𝕏. Because it's a Twitter clone. A purist Twitter clone whose developers intentionally reject feature requests because the requested features don't fit into their image of purist, minimalist, old-school, original-gangsta microblogging. They want to keep Mastodon a slightly more glorified SMS than 𝕏.
Mastodon isn't even the only microblogging server application in the Fediverse. It isn't even the best at that. 80-90% of Mastodon's users don't and probably will never realise that Mastodon is an intentionally crippled resource hog. Many believe that Mastodon is the fully-featured be-all, end-all of social networking.
By the way, even the Mastodon developers claim that Mastodon is fully featured. I've had a Mastodon dev try hard to convince me that Mastodon is fully featured although I've told him that I'm on Hubzilla. He essentially tried to tell me that Mastodon has every last feature that Hubzilla has plus even more on top.
In reality, Mastodon isn't the fully-featured be-all, end-all of social networking. It isn't even a social network. It's social media, just like 𝕏 is social media. It's designed for pumping out content and being followed because it's designed as a Twitter-like microblogging application. And it isn't even the best at microblogging.
Almost everyone on Mastodon is fully convinced that Mastodon has to be the best. After all, it's the biggest. It's what everyone chose.
No.
Mastodon is the biggest because everyone who wants to leave 𝕏 or Threads or Bluesky is railroaded to Mastodon. It's the biggest because all the newbies are only told about Mastodon. It's the biggest because none of the newbies even learn upon on-boarding that other 𝕏 alternatives exist in the Fediverse, that anything else exists in the Fediverse other than Mastodon. It's the biggest because mainstream media, tech media and even Fediverse activists only ever talk about Mastodon, Mastodon, Mastodon. (Granted, it's also the biggest because it's the only one with an official phone app in the Apple App Store and the Google Play Store. Even though that app sucks.)
All these Mastodon users who claim that Mastodon is the best choice don't realise that they themselves did, in fact, not choose Mastodon. They didn't know they had a choice. All they were told about was Mastodon. Seriously, if they'd had a choice, they'd probably be on Sharkey now and not on Mastodon.
I've read what people had to say who moved from Friendica to Misskey. Or to now defunct Calckey/Firefish. Or to Sharkey. Or to Akkoma. All these are microblogging server applications in the Fediverse. But none of them are intentionally crippled to stay close to Twitter, at least not to such a degree as Mastodon.
It was nothing short of eye-opening to them. Only by daily-driving something else than Mastodon did they realise what the non-Mastodon Fediverse can be like. And how crippled Mastodon actually is. That Mastodon is far from being the absolute pinnacle in decentralised social media.
They no longer had only 500 characters. They had thousands of characters. They would have had thousands of characters on every server running that software without having to ask around which one has more than 500 characters. It felt like a restraint being removed which they had never considered a restraint, at least not that much of it.
They saw text formatting which they considered technologically absolutely impossible in the Fediverse when they were on Mastodon. In fact, they had considered text formatting entirely impossible while on Mastodon until they had come across the first message from outside with text formatting. Actual text formatting, not Unicode trickery. Now they suddenly saw a lot of the stuff that Mastodon's HTML sanitiser removes. And they themselves could use it!
If they were on one of the *keys, they no longer had a timeline of single-message piecemeal. For the first time ever, they experienced what it's like to have something else than single-message piecemeal. Namely entire conversations right in front of them, right away. Without having to dig for them first.
They had features which they had always wished the Fediverse may introduce. They never knew that the Fediverse does have these features, only Mastodon doesn't. They had features that were completely unimagiable to them in the Fediverse.
There are users who have moved from Mastodon to something "minimalist" and lightweight like snac or GoToSocial, often on self-hosted, single-user, private servers. Even they suddenly had features they didn't have on Mastodon. Mind you, while not missing a single Mastodon feature (except maybe for a built-in Web UI).
And that's just the microblogging side of the Fediverse. None of this is actual social networking. You know, what Facebook does.
First of all, if it's about following and being followed, it's social media. A social network doesn't have followers. In case you don't know, Facebook doesn't have followers. It has "friends". Bidirectional connections. Not 𝕏/Mastodon-like mutuals which are two connections, one in each direction, but one connection that goes both ways.
Besides, there are even more important social networking features missing from the microblogging side of the Fediverse.
Where are the contact suggestions? Where does Mastodon suggest new contacts based on how many contacts you have in common with them? Where does Mastodon suggest new contacts based on what profile information you have in common with them?
Oh, right, the latter is impossible because Mastodon doesn't have profile fields with defined purposes. In fact, where are these? Every good social network has them! But Mastodon only gives you four all-purpose profile fields (just like Mastodon only gives you four of everything, four file attachments, four options in polls...).
Where is the list of unread posts, unread comments and other unnoticed actions? How are you to make sure you really catch everything your friends do? Because you can't do that if all you have is a timeline to scroll through until you no longer see new stuff. If you manage to scroll down that far. And only absolute newbies can do that on Mastodon because they hardly follow anyone.
Where are groups? Seriously, I've lost count of how many times Mastodon users said "the Fediverse" must introduce something like Facebook Groups. The huge majority of Mastodon users is fully convinced that the Fediverse does not have groups in any shape or form because Mastodon doesn't have them.
Where are all these things? In the Fediverse, no less? Where are they?
I'll tell you where they are.
Friendica. Hubzilla. (streams). Forte.
The actual social networking side of the Fediverse (although Hubzilla is more like a social CMS or a "social Swiss army knife" that you can also use as a Facebook-like social networking application). I mean, I've already explained that Friendica was created in 2010 as a Facebook alternative. Not a faithful Facebook clone, though, but better than Facebook.
Mike Macgirvin took over from Facebook what social networks really need. And Farmville isn't that, and spying on your users and passing that data on to the NSA and selling it to the highest bidder isn't that, so he didn't take over that. He didn't want to build a clone that also adopts the bad sides just to be as close to the original as possible.
He took over the detailed profiles with profile fields with dedicated purposes. He took over profile privacy settings. In general, he took over a lot of privacy features. He took over advanced user discovery and connection suggestions. He took over bidirectional connections, only without that silly name "friends". He took over groups with moderation, only that a group on Friendica is just another account with a special automated reposter. He took over enclosed threaded conversations with one post at the top and otherwise only comments. He took over a "timeline" of full conversations as the default. He took over the event calendar. And so forth.
Instead, he added useful stuff on top. He gave Friendica all the posting features to make it fully capable of long-form blogging with all bells and whistles. No character limit (except for in the database, but I think that was over 65,000 back in the day already). All HTML text formatting features (only that Friendica only used BBcode back then; now it can optionally also use Markdown). A post/thread title. Summaries. Embedded images and other media with no limit in number. He even added a spoiler tag like in forums that can hide parts of a message.
He took care of privacy beyond what Facebook had to offer. He introduced a permissions system. Friendica got multiple profile per account, only one of which is public, so that you can show different sides of yourself to different connections.
Now, if you want to embed images or other media in your messages, you have to store them somewhere. And not everyone could be expected to set up a little file space somewhere. So he built a file space into Friendica, one that can even be used as a Dropbox alternative, all the way to restricted access to certain directories.
Mike also added a content warning system that automatically generates content warnings on the reader's side, based on a keyword list. If you need something behind content warnings, add the keywords to the list, and you'll have the respective content warnings, but the next user receiving the self-same post or comment does not have these content warnings if they don't need them.
One important part of what makes Friendica Friendica is being able to connect to a whole lot of stuff. For example, Friendica could federate with StatusNet via the OStatus protocol from the get-go; this is also how it immediately federated with Mastodon when the latter was launched. Mastodon generates an RSS feed, something that many users don't know. Friendica not only generates an Atom feed, but it can subscribe to feeds. Friendica can "federate" with e-mail. Over time, more and more connection features were added, including Tumblr, Twitter (!), Facebook (only for a few years before Facebook crippled it) and a WordPress cross-poster.
Lastly, he made it possible for third parties to add extra features by implementing an add-on system.
I dare those who are fully convinced that Mastodon is the best Facebook alternative possible to use Friendica for a year. Not only dip one toe in to the water, but use it as their one and only daily driver for everything they've used Mastodon for. Not scratching the surface and using it like Twitter while ignoring any and all features the Twitter they remember didn't have, but going all in. In fact, I dare those who are fully convinced that Mastodon is perfect and fully-featured to do the same.
And then there's Hubzilla. It came to exist by Mike forking Friendica in 2011, then forking that fork the same year, then rewriting that fork of a fork in 2012, then repurposing, rebranding, repositioning and greatly expanding it in 2015. Long story.
Hubzilla adds even more stuff on top. Most importantly, it introduced nomadic identity (https://joinfediverse.wiki/Nomadic_identity) in 2012.
Hubzilla, or its 2012 prototype form named Red, became the first decentralised social software that uncoupled the identity from the login. This was necessary for nomadic identity, but it also introduced the option to have multiple independent identities, basically what's an account elsewhere, on the same account, the same login. This makes sense, given the many different roles and purposes a Hubzilla channel can have. The big advantage over having multiple separate accounts is that you can switch between the channels on your account without logging out and back in.
Hubzilla, or its 2012 prototype form named Red, got an even more advanced and fine-grained permissions system. Hubzilla has 17 individual permissions on three levels, channel level, contact level, content level. At channel level, each one has seven or eight permission options to choose from, depending on whether or not it makes sense to give a permission to everyone on the Internet.
Mike added optional features to Hubzilla that were previously unseen on social anything, features that you'd rather expect from a CMS and maybe not even from that. Non-federating long-form articles. Planning cards that are based on these articles. Wikis that can be formatted with BBcode or Markdown. Webpages that can be formatted with BBcode, Markdown or HTML, that can include dynamic content from elsewhere on the channel, and that can add extra content to the channel pages.
Hubzilla can even act as groupware. It has a CalDAV calendar server; the event calendar can double as a crude UI for the CalDAV calendars. It has an optional CardDAV addressbook server. Its built-in file storage can be accessed via WebDAV, so you theoretically even have some cloud file space you can mount as a network drive. Rather recently, there was even a way found to tie Collabora Office into Hubzilla.
If you should ever read about Bonfire: Bonfire is Hubzilla ordered from Wish.com. Whatever Bonfire promises to have or to introduce has been available as a rock-solid stable feature on Hubzilla for over a decade. Bonfire only gets away with what it's trying to do because nobody knows Hubzilla.
I think it's safe to say that those who "chose" Mastodon didn't choose it over the rest of the Fediverse because it's better. They "chose" it because they didn't even know they have a choice.
As for your post, the technology for redeveloping socialising is there. And it certainly isn't Mastodon, and it never will be Mastodon. Mastodon can't be that due to its design philosophy, due to it being a Twitter clone, due to its own developers intentionally crippling it.
If you want to move on from 1-way interaction, you have to move on from 1-way connections. Move on from Twitter followers to Facebook friends.
You have to offer better options for the users than shouting into the void, attaching a bunch of hashtags and hoping that some of their followers or someone who is following one of the hashtags happens to be bothered to scroll down their timeline far enough.
You have to make sure that people don't miss content due to basic design and philosophy decisions. You have to make sure that people don't miss content because they simply never know that this content is there in the first place, because they can't scroll down far enough their timelines until they reach that content. You need something else than a timeline of single messages to scroll down with the user not having an idea just how far down that timeline goes. You have to tell the user how much unread content there is, what it is, where it is, and take the user directly to that unread content.
You have to stop presenting content to users as a long list of single posts and more single posts with only tiny details telling them that these posts are, in fact, part of a longer conversation which they don't see. Where they have to click or tap themselves through various UI pages to see that post in its context. Users must see the whole conversation Right. Off. The bat.
You need groups. Not kluged onto something that had no group support whatsoever two seconds earlier, not intentionally crippled, not crippled by the technology they're built upon, not intentionally re-invented to be incompatible with whatever already exists (and this is how Mastodon would do them). But fully functional, on an appropriate base, interoperable, user-moderated, optionally private, optionally hiding from directories.
If you want to go "social", you really have to go social. You have to go Facebook, not Twitter.
Users must find other users based on common interests. Or users living close to them. Or users with lots of contacts in common with them. Not by being on the same local/regional server of the same server about a certain topic. Not by searching for hashtags in the main profile text. But by examining specialised profile fields and the contacts.
Users must have such users suggested to them as new connections. Users must have such users at the top of their directory. This is how Facebook does it. And this is one thing that Facebook has always done right.
Again, Mastodon will never offer any of this. But that doesn't mean that you'll have to compromise and lower your expectations. Because you don't have to. There are server applications in the Fediverse, fully federated with Mastodon, that offer literally all of that. They exist right now. And some of them have existed for longer than Mastodon.
If you need something better than today's Mastodon, stop wishing for a better Mastodon. Instead, use something that's better and more appropriate for the job than Mastodon right now. For it exists right now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #500Characters #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #Fediverse #Mastodon #MastodonFediverse #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Friendica #Hubzilla #Streams #(streams) #Forte #Privacy #Permission #Permissions #Groups #FediverseGroups #FediGroups #NomadicIdentity #MastodonCentricity #MastodonNormativity -
The NomadPub intro page now includes a "Research" section:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#research
I listed the most important open research problems there: key management (alt-DIDs), alternative transports, E2EE and generic servers.
-
The NomadPub intro page now includes a "Research" section:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#research
I listed the most important open research problems there: key management (alt-DIDs), alternative transports, E2EE and generic servers.
-
The NomadPub intro page now includes a "Research" section:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#research
I listed the most important open research problems there: key management (alt-DIDs), alternative transports, E2EE and generic servers.
-
The NomadPub intro page now includes a "Research" section:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#research
I listed the most important open research problems there: key management (alt-DIDs), alternative transports, E2EE and generic servers.
-
@Sea @C. Are you absolutely certain that they are all Mastodon accounts? Have you checked their profiles at the sources (in a Web browser, in case you're on a phone with a dedicated Mastodon app) and seen a Mastodon profile page?
I mean, yes, some of them are on Mastodon. But not all Fediverse actors that at least sometimes appear in several instances are on Mastodon.
See, certain non-Mastodon Fediverse server software has a feature called "nomadic identity" (https://joinfediverse.wiki/Nomadic_identity). This makes it possible to create clones (live backups sync'd bidirectionally against each other in real time) of one's identity with everything attached to it on other servers. First and foremost, it's Hubzilla (https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) that offers this feature, and it has since 2012.
What you see in this case is not two separate Fediverse identities, one of which is an automated reposter bot. It's one cloned nomadic identity, only that Mastodon can't understand it as such because it lacks the technical means to do so.
The idea behind this is resilience by redundancy: One server with your identity goes down, and you lose nothing because you still have the exact self-same identity with everything on at least one other server. Even if that server goes back online, the instance of your identity on it catches up with the others. The whole concept was born from Friendica servers disappearing and their users losing everything.
Fediverse server applications that know nomadic identity see all instances of a cloned identity as one and the same identity.
But Fediverse server applications like Mastodon that don't know nomadic identity see them as separate Fediverse accounts with separate identities.
For example, the Hubzilla channel that I'm replying from right now has one clone, so it has two instances. Mastodon understands them as two individual accounts. So do all Mastodon users, also because the huge majority of them has never heard of nomadic identity.
Thus, there are Mastodon users who follow both my main instance and my clone because they think these are two separate accounts. And now they end up receiving each one of my posts twice. Also, the federated timeline of the Mastodon server that they're on lists each one of my posts twice.
The latter also happens when one user on any given Mastodon server follows my main instance, and another user follows my clone.
Most Mastodon users, upon seeing my posts twice, will assume that I'm running some automated reposting bot (technically speaking, I could, but I don't) that serves to a) increase my reach and b) circumvent mutes and blocks. At least some may be tempted to block both my original instance and my clone.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Clone #Clones #NomadicIdentity -
@Sea @C. Are you absolutely certain that they are all Mastodon accounts? Have you checked their profiles at the sources (in a Web browser, in case you're on a phone with a dedicated Mastodon app) and seen a Mastodon profile page?
I mean, yes, some of them are on Mastodon. But not all Fediverse actors that at least sometimes appear in several instances are on Mastodon.
See, certain non-Mastodon Fediverse server software has a feature called "nomadic identity" (https://joinfediverse.wiki/Nomadic_identity). This makes it possible to create clones (live backups sync'd bidirectionally against each other in real time) of one's identity with everything attached to it on other servers. First and foremost, it's Hubzilla (https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) that offers this feature, and it has since 2012.
What you see in this case is not two separate Fediverse identities, one of which is an automated reposter bot. It's one cloned nomadic identity, only that Mastodon can't understand it as such because it lacks the technical means to do so.
The idea behind this is resilience by redundancy: One server with your identity goes down, and you lose nothing because you still have the exact self-same identity with everything on at least one other server. Even if that server goes back online, the instance of your identity on it catches up with the others. The whole concept was born from Friendica servers disappearing and their users losing everything.
Fediverse server applications that know nomadic identity see all instances of a cloned identity as one and the same identity.
But Fediverse server applications like Mastodon that don't know nomadic identity see them as separate Fediverse accounts with separate identities.
For example, the Hubzilla channel that I'm replying from right now has one clone, so it has two instances. Mastodon understands them as two individual accounts. So do all Mastodon users, also because the huge majority of them has never heard of nomadic identity.
Thus, there are Mastodon users who follow both my main instance and my clone because they think these are two separate accounts. And now they end up receiving each one of my posts twice. Also, the federated timeline of the Mastodon server that they're on lists each one of my posts twice.
The latter also happens when one user on any given Mastodon server follows my main instance, and another user follows my clone.
Most Mastodon users, upon seeing my posts twice, will assume that I'm running some automated reposting bot (technically speaking, I could, but I don't) that serves to a) increase my reach and b) circumvent mutes and blocks. At least some may be tempted to block both my original instance and my clone.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Clone #Clones #NomadicIdentity -
@Sea @C. Are you absolutely certain that they are all Mastodon accounts? Have you checked their profiles at the sources (in a Web browser, in case you're on a phone with a dedicated Mastodon app) and seen a Mastodon profile page?
I mean, yes, some of them are on Mastodon. But not all Fediverse actors that at least sometimes appear in several instances are on Mastodon.
See, certain non-Mastodon Fediverse server software has a feature called "nomadic identity" (https://joinfediverse.wiki/Nomadic_identity). This makes it possible to create clones (live backups sync'd bidirectionally against each other in real time) of one's identity with everything attached to it on other servers. First and foremost, it's Hubzilla (https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) that offers this feature, and it has since 2012.
What you see in this case is not two separate Fediverse identities, one of which is an automated reposter bot. It's one cloned nomadic identity, only that Mastodon can't understand it as such because it lacks the technical means to do so.
The idea behind this is resilience by redundancy: One server with your identity goes down, and you lose nothing because you still have the exact self-same identity with everything on at least one other server. Even if that server goes back online, the instance of your identity on it catches up with the others. The whole concept was born from Friendica servers disappearing and their users losing everything.
Fediverse server applications that know nomadic identity see all instances of a cloned identity as one and the same identity.
But Fediverse server applications like Mastodon that don't know nomadic identity see them as separate Fediverse accounts with separate identities.
For example, the Hubzilla channel that I'm replying from right now has one clone, so it has two instances. Mastodon understands them as two individual accounts. So do all Mastodon users, also because the huge majority of them has never heard of nomadic identity.
Thus, there are Mastodon users who follow both my main instance and my clone because they think these are two separate accounts. And now they end up receiving each one of my posts twice. Also, the federated timeline of the Mastodon server that they're on lists each one of my posts twice.
The latter also happens when one user on any given Mastodon server follows my main instance, and another user follows my clone.
Most Mastodon users, upon seeing my posts twice, will assume that I'm running some automated reposting bot (technically speaking, I could, but I don't) that serves to a) increase my reach and b) circumvent mutes and blocks. At least some may be tempted to block both my original instance and my clone.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Clone #Clones #NomadicIdentity -
@Sea @C. Are you absolutely certain that they are all Mastodon accounts? Have you checked their profiles at the sources (in a Web browser, in case you're on a phone with a dedicated Mastodon app) and seen a Mastodon profile page?
I mean, yes, some of them are on Mastodon. But not all Fediverse actors that at least sometimes appear in several instances are on Mastodon.
See, certain non-Mastodon Fediverse server software has a feature called "nomadic identity" (https://joinfediverse.wiki/Nomadic_identity). This makes it possible to create clones (live backups sync'd bidirectionally against each other in real time) of one's identity with everything attached to it on other servers. First and foremost, it's Hubzilla (https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) that offers this feature, and it has since 2012.
What you see in this case is not two separate Fediverse identities, one of which is an automated reposter bot. It's one cloned nomadic identity, only that Mastodon can't understand it as such because it lacks the technical means to do so.
The idea behind this is resilience by redundancy: One server with your identity goes down, and you lose nothing because you still have the exact self-same identity with everything on at least one other server. Even if that server goes back online, the instance of your identity on it catches up with the others. The whole concept was born from Friendica servers disappearing and their users losing everything.
Fediverse server applications that know nomadic identity see all instances of a cloned identity as one and the same identity.
But Fediverse server applications like Mastodon that don't know nomadic identity see them as separate Fediverse accounts with separate identities.
For example, the Hubzilla channel that I'm replying from right now has one clone, so it has two instances. Mastodon understands them as two individual accounts. So do all Mastodon users, also because the huge majority of them has never heard of nomadic identity.
Thus, there are Mastodon users who follow both my main instance and my clone because they think these are two separate accounts. And now they end up receiving each one of my posts twice. Also, the federated timeline of the Mastodon server that they're on lists each one of my posts twice.
The latter also happens when one user on any given Mastodon server follows my main instance, and another user follows my clone.
Most Mastodon users, upon seeing my posts twice, will assume that I'm running some automated reposting bot (technically speaking, I could, but I don't) that serves to a) increase my reach and b) circumvent mutes and blocks. At least some may be tempted to block both my original instance and my clone.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Clone #Clones #NomadicIdentity -
@Sea @C. Are you absolutely certain that they are all Mastodon accounts? Have you checked their profiles at the sources (in a Web browser, in case you're on a phone with a dedicated Mastodon app) and seen a Mastodon profile page?
I mean, yes, some of them are on Mastodon. But not all Fediverse actors that at least sometimes appear in several instances are on Mastodon.
See, certain non-Mastodon Fediverse server software has a feature called "nomadic identity" (https://joinfediverse.wiki/Nomadic_identity). This makes it possible to create clones (live backups sync'd bidirectionally against each other in real time) of one's identity with everything attached to it on other servers. First and foremost, it's Hubzilla (https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) that offers this feature, and it has since 2012.
What you see in this case is not two separate Fediverse identities, one of which is an automated reposter bot. It's one cloned nomadic identity, only that Mastodon can't understand it as such because it lacks the technical means to do so.
The idea behind this is resilience by redundancy: One server with your identity goes down, and you lose nothing because you still have the exact self-same identity with everything on at least one other server. Even if that server goes back online, the instance of your identity on it catches up with the others. The whole concept was born from Friendica servers disappearing and their users losing everything.
Fediverse server applications that know nomadic identity see all instances of a cloned identity as one and the same identity.
But Fediverse server applications like Mastodon that don't know nomadic identity see them as separate Fediverse accounts with separate identities.
For example, the Hubzilla channel that I'm replying from right now has one clone, so it has two instances. Mastodon understands them as two individual accounts. So do all Mastodon users, also because the huge majority of them has never heard of nomadic identity.
Thus, there are Mastodon users who follow both my main instance and my clone because they think these are two separate accounts. And now they end up receiving each one of my posts twice. Also, the federated timeline of the Mastodon server that they're on lists each one of my posts twice.
The latter also happens when one user on any given Mastodon server follows my main instance, and another user follows my clone.
Most Mastodon users, upon seeing my posts twice, will assume that I'm running some automated reposting bot (technically speaking, I could, but I don't) that serves to a) increase my reach and b) circumvent mutes and blocks. At least some may be tempted to block both my original instance and my clone.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Clone #Clones #NomadicIdentity -
@Patrick Leavy A whole lot. Sorry, but this will be very very very long again.
I don't know if you've read my previous (very long) commentary. But just implementing one or two FEPs won't get you the same full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) that Hubzilla (what I'm writing from right now; https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) has had since 2012. And having this level of nomadic identity has to be the goal.
What has to be done is:
Take something like Mastodon.
Non-nomadic.
Where your account, your login, equals your identity.Make your identity cloneable
Now, before you can make identities nomadic, you have to uncouple them from the login, from the account.
Mastodon has to introduce a sort of container for your identity, like the channels that Hubzilla, (streams) and Forte have always had (https://joinfediverse.wiki/Channels_(Hubzilla_&_(streams))). This is necessary so that a future nomadic Mastodon will know what to clone and what not to clone. For example, cloning your password is dangerous nonsense.
So, everything that makes up your account except for your login credentials will have to be moved into this container.- your short name
- your long name
- your profile images, including alt-texts
- your profile
- your followers
- your followed
- your toots, including stats like faves, boosts etc.
- copies of the conversation trees of all your toots, including stats like faves, boosts etc. as well as attached files for each message
- all files you've ever attached to toots
- your settings
- your filters
- your mutes
- your blocks
- your server blocks
- etc.
Change your login
Also, your login will have to change from short name + passphrase to e-mail + passphrase. Your short name is part of your identity, it's in the container, it will be cloned, so it can't be used to log you in anymore.
In order for this to work, half of Mastodon's server backend will have to be rewritten.Decentralised IDs
Next, Mastodon must switch from the Webfinger IDs that it uses now to decentralised IDs as per FEP-ef61. For a while, I guess, it will have to use both next to one another. Then it will have to phase out its Webfinger IDs.
The decentralised IDs must be tested against other Fediverse software that already understands them or that's nomadic itself: (streams), Forte, Mitra, Tootik. For example, @silverpill of Mitra and @Mike Macgirvin of (streams) and Forte must test whether their software correctly understands Mastodon's DIDs. And the Mastodon developers must test whether Mastodon correctly understands the DIDs from Fediverse server applications that already use them.
Once it has gotten rid of its Webfinger IDs, the next phase can start.Implement cloning within Mastodon
The central element of nomadic identity is not the ability to move your identity. That's only a byproduct of cloning your identity.
A clone, in nomadic identity, is a full backup of the container with your identity in it. A real-time, live, bidirectional backup that you can log into and use just like the "original". The clone always has the same idea as the original, regardless of which server it's on.
The key elements of clones and cloning must be implemented and tested:- cloning an identity container to a different server after registering a new, blank account there
- cloning an identity container to a different server where you already have an account with a different containerised identity
- anything that happens on the original being sync'd to the clone
- anything that happens on the clone being sync'd to the original
- clone going offline, things happening on the original, clone coming back online, things that happened on the original being reliably sync'd to the clone
- original going offline, clone still working with the ID based on the original's domain
- original going offline, things happening on the clone, original coming back online, things that happened on the clone being reliably sync'd to the original
- making additional clones of an identity container that has already been cloned at least once
- the whole syncing shebang from the original to any number of clones
- the whole syncing shebang from one of the clones to the original and also directly to the other clones
- declaring one of the clones the new original, thus changing the ID of both the former original and all clones
Implement moving within Mastodon
Only when cloning works reliably, we can talk about moving, even though that's what everyone on Mastodon is giddy about.
Why? Because moving involves cloning. It's an automated process. At least it is on Hubzilla, (streams) and Forte, and it really should be one on nomadic Mastodon.
Basically, first you make a clone.
Then you declare the clone the new original, and your old original is demoted to a clone.
Then you have to wait until your change of ID from changing the original has federated to all your followers and followed and everywhere and whatnot.
Then, one last sync so that both the former-clone-now-new-original and the old-original-now-clone are really identical, and you won't lose any data.
Then your old-original-now-clone is deleted. We don't want to leave any dead stuff behind, now, do we?
Lastly, if your old account where your old original used to reside has no other identity on it, the whole account is deleted. In nomadic containerised identity, accounts cannot/should not exist with no identity container on them.Cloning and moving beyond Mastodon
The last possible step is still utter science-fiction: Cloning or moving from Mastodon to something else that's nomadic and understands FEP-ef61.
Cloning or moving from Mastodon to Mitra. From Mastodon to Tootik. From Mastodon to (streams). From Mastodon to Forte. Oh, and maybe also back to Mastodon.
The difficult part is not only to make Mastodon capable of cloning identity containers to other nomadic software. And to make Mastodon accept identity containers from other nomadic software being cloned to Mastodon. I mean, this would be difficult already. (streams) and Forte are vastly, vastly different from Mastodon.
No, the difficult part is to make these four capable of cloning from or to someplace else. As it stands now, you can only clone from Mitra to Mitra, from Tootik to Tootik, from (streams) to (streams), from Forte to Forte. Even cloning between (streams) and Forte has never been possible, even though they're very similar. Oh, and cloning from and to Hubzilla is another story because Hubzilla doesn't have FEP-ef61 implemented.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #Tootik #NomadicIdentity -
@Patrick Leavy A whole lot. Sorry, but this will be very very very long again.
I don't know if you've read my previous (very long) commentary. But just implementing one or two FEPs won't get you the same full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) that Hubzilla (what I'm writing from right now; https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) has had since 2012. And having this level of nomadic identity has to be the goal.
What has to be done is:
Take something like Mastodon.
Non-nomadic.
Where your account, your login, equals your identity.Make your identity cloneable
Now, before you can make identities nomadic, you have to uncouple them from the login, from the account.
Mastodon has to introduce a sort of container for your identity, like the channels that Hubzilla, (streams) and Forte have always had (https://joinfediverse.wiki/Channels_(Hubzilla_&_(streams))). This is necessary so that a future nomadic Mastodon will know what to clone and what not to clone. For example, cloning your password is dangerous nonsense.
So, everything that makes up your account except for your login credentials will have to be moved into this container.- your short name
- your long name
- your profile images, including alt-texts
- your profile
- your followers
- your followed
- your toots, including stats like faves, boosts etc.
- copies of the conversation trees of all your toots, including stats like faves, boosts etc. as well as attached files for each message
- all files you've ever attached to toots
- your settings
- your filters
- your mutes
- your blocks
- your server blocks
- etc.
Change your login
Also, your login will have to change from short name + passphrase to e-mail + passphrase. Your short name is part of your identity, it's in the container, it will be cloned, so it can't be used to log you in anymore.
In order for this to work, half of Mastodon's server backend will have to be rewritten.Decentralised IDs
Next, Mastodon must switch from the Webfinger IDs that it uses now to decentralised IDs as per FEP-ef61. For a while, I guess, it will have to use both next to one another. Then it will have to phase out its Webfinger IDs.
The decentralised IDs must be tested against other Fediverse software that already understands them or that's nomadic itself: (streams), Forte, Mitra, Tootik. For example, @silverpill of Mitra and @Mike Macgirvin of (streams) and Forte must test whether their software correctly understands Mastodon's DIDs. And the Mastodon developers must test whether Mastodon correctly understands the DIDs from Fediverse server applications that already use them.
Once it has gotten rid of its Webfinger IDs, the next phase can start.Implement cloning within Mastodon
The central element of nomadic identity is not the ability to move your identity. That's only a byproduct of cloning your identity.
A clone, in nomadic identity, is a full backup of the container with your identity in it. A real-time, live, bidirectional backup that you can log into and use just like the "original". The clone always has the same idea as the original, regardless of which server it's on.
The key elements of clones and cloning must be implemented and tested:- cloning an identity container to a different server after registering a new, blank account there
- cloning an identity container to a different server where you already have an account with a different containerised identity
- anything that happens on the original being sync'd to the clone
- anything that happens on the clone being sync'd to the original
- clone going offline, things happening on the original, clone coming back online, things that happened on the original being reliably sync'd to the clone
- original going offline, clone still working with the ID based on the original's domain
- original going offline, things happening on the clone, original coming back online, things that happened on the clone being reliably sync'd to the original
- making additional clones of an identity container that has already been cloned at least once
- the whole syncing shebang from the original to any number of clones
- the whole syncing shebang from one of the clones to the original and also directly to the other clones
- declaring one of the clones the new original, thus changing the ID of both the former original and all clones
Implement moving within Mastodon
Only when cloning works reliably, we can talk about moving, even though that's what everyone on Mastodon is giddy about.
Why? Because moving involves cloning. It's an automated process. At least it is on Hubzilla, (streams) and Forte, and it really should be one on nomadic Mastodon.
Basically, first you make a clone.
Then you declare the clone the new original, and your old original is demoted to a clone.
Then you have to wait until your change of ID from changing the original has federated to all your followers and followed and everywhere and whatnot.
Then, one last sync so that both the former-clone-now-new-original and the old-original-now-clone are really identical, and you won't lose any data.
Then your old-original-now-clone is deleted. We don't want to leave any dead stuff behind, now, do we?
Lastly, if your old account where your old original used to reside has no other identity on it, the whole account is deleted. In nomadic containerised identity, accounts cannot/should not exist with no identity container on them.Cloning and moving beyond Mastodon
The last possible step is still utter science-fiction: Cloning or moving from Mastodon to something else that's nomadic and understands FEP-ef61.
Cloning or moving from Mastodon to Mitra. From Mastodon to Tootik. From Mastodon to (streams). From Mastodon to Forte. Oh, and maybe also back to Mastodon.
The difficult part is not only to make Mastodon capable of cloning identity containers to other nomadic software. And to make Mastodon accept identity containers from other nomadic software being cloned to Mastodon. I mean, this would be difficult already. (streams) and Forte are vastly, vastly different from Mastodon.
No, the difficult part is to make these four capable of cloning from or to someplace else. As it stands now, you can only clone from Mitra to Mitra, from Tootik to Tootik, from (streams) to (streams), from Forte to Forte. Even cloning between (streams) and Forte has never been possible, even though they're very similar. Oh, and cloning from and to Hubzilla is another story because Hubzilla doesn't have FEP-ef61 implemented.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #Tootik #NomadicIdentity -
@Patrick Leavy A whole lot. Sorry, but this will be very very very long again.
I don't know if you've read my previous (very long) commentary. But just implementing one or two FEPs won't get you the same full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) that Hubzilla (what I'm writing from right now; https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) has had since 2012. And having this level of nomadic identity has to be the goal.
What has to be done is:
Take something like Mastodon.
Non-nomadic.
Where your account, your login, equals your identity.Make your identity cloneable
Now, before you can make identities nomadic, you have to uncouple them from the login, from the account.
Mastodon has to introduce a sort of container for your identity, like the channels that Hubzilla, (streams) and Forte have always had (https://joinfediverse.wiki/Channels_(Hubzilla_&_(streams))). This is necessary so that a future nomadic Mastodon will know what to clone and what not to clone. For example, cloning your password is dangerous nonsense.
So, everything that makes up your account except for your login credentials will have to be moved into this container.- your short name
- your long name
- your profile images, including alt-texts
- your profile
- your followers
- your followed
- your toots, including stats like faves, boosts etc.
- copies of the conversation trees of all your toots, including stats like faves, boosts etc. as well as attached files for each message
- all files you've ever attached to toots
- your settings
- your filters
- your mutes
- your blocks
- your server blocks
- etc.
Change your login
Also, your login will have to change from short name + passphrase to e-mail + passphrase. Your short name is part of your identity, it's in the container, it will be cloned, so it can't be used to log you in anymore.
In order for this to work, half of Mastodon's server backend will have to be rewritten.Decentralised IDs
Next, Mastodon must switch from the Webfinger IDs that it uses now to decentralised IDs as per FEP-ef61. For a while, I guess, it will have to use both next to one another. Then it will have to phase out its Webfinger IDs.
The decentralised IDs must be tested against other Fediverse software that already understands them or that's nomadic itself: (streams), Forte, Mitra, Tootik. For example, @silverpill of Mitra and @Mike Macgirvin of (streams) and Forte must test whether their software correctly understands Mastodon's DIDs. And the Mastodon developers must test whether Mastodon correctly understands the DIDs from Fediverse server applications that already use them.
Once it has gotten rid of its Webfinger IDs, the next phase can start.Implement cloning within Mastodon
The central element of nomadic identity is not the ability to move your identity. That's only a byproduct of cloning your identity.
A clone, in nomadic identity, is a full backup of the container with your identity in it. A real-time, live, bidirectional backup that you can log into and use just like the "original". The clone always has the same idea as the original, regardless of which server it's on.
The key elements of clones and cloning must be implemented and tested:- cloning an identity container to a different server after registering a new, blank account there
- cloning an identity container to a different server where you already have an account with a different containerised identity
- anything that happens on the original being sync'd to the clone
- anything that happens on the clone being sync'd to the original
- clone going offline, things happening on the original, clone coming back online, things that happened on the original being reliably sync'd to the clone
- original going offline, clone still working with the ID based on the original's domain
- original going offline, things happening on the clone, original coming back online, things that happened on the clone being reliably sync'd to the original
- making additional clones of an identity container that has already been cloned at least once
- the whole syncing shebang from the original to any number of clones
- the whole syncing shebang from one of the clones to the original and also directly to the other clones
- declaring one of the clones the new original, thus changing the ID of both the former original and all clones
Implement moving within Mastodon
Only when cloning works reliably, we can talk about moving, even though that's what everyone on Mastodon is giddy about.
Why? Because moving involves cloning. It's an automated process. At least it is on Hubzilla, (streams) and Forte, and it really should be one on nomadic Mastodon.
Basically, first you make a clone.
Then you declare the clone the new original, and your old original is demoted to a clone.
Then you have to wait until your change of ID from changing the original has federated to all your followers and followed and everywhere and whatnot.
Then, one last sync so that both the former-clone-now-new-original and the old-original-now-clone are really identical, and you won't lose any data.
Then your old-original-now-clone is deleted. We don't want to leave any dead stuff behind, now, do we?
Lastly, if your old account where your old original used to reside has no other identity on it, the whole account is deleted. In nomadic containerised identity, accounts cannot/should not exist with no identity container on them.Cloning and moving beyond Mastodon
The last possible step is still utter science-fiction: Cloning or moving from Mastodon to something else that's nomadic and understands FEP-ef61.
Cloning or moving from Mastodon to Mitra. From Mastodon to Tootik. From Mastodon to (streams). From Mastodon to Forte. Oh, and maybe also back to Mastodon.
The difficult part is not only to make Mastodon capable of cloning identity containers to other nomadic software. And to make Mastodon accept identity containers from other nomadic software being cloned to Mastodon. I mean, this would be difficult already. (streams) and Forte are vastly, vastly different from Mastodon.
No, the difficult part is to make these four capable of cloning from or to someplace else. As it stands now, you can only clone from Mitra to Mitra, from Tootik to Tootik, from (streams) to (streams), from Forte to Forte. Even cloning between (streams) and Forte has never been possible, even though they're very similar. Oh, and cloning from and to Hubzilla is another story because Hubzilla doesn't have FEP-ef61 implemented.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #Tootik #NomadicIdentity -
@Patrick Leavy A whole lot. Sorry, but this will be very very very long again.
I don't know if you've read my previous (very long) commentary. But just implementing one or two FEPs won't get you the same full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) that Hubzilla (what I'm writing from right now; https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) has had since 2012. And having this level of nomadic identity has to be the goal.
What has to be done is:
Take something like Mastodon.
Non-nomadic.
Where your account, your login, equals your identity.Make your identity cloneable
Now, before you can make identities nomadic, you have to uncouple them from the login, from the account.
Mastodon has to introduce a sort of container for your identity, like the channels that Hubzilla, (streams) and Forte have always had (https://joinfediverse.wiki/Channels_(Hubzilla_&_(streams))). This is necessary so that a future nomadic Mastodon will know what to clone and what not to clone. For example, cloning your password is dangerous nonsense.
So, everything that makes up your account except for your login credentials will have to be moved into this container.- your short name
- your long name
- your profile images, including alt-texts
- your profile
- your followers
- your followed
- your toots, including stats like faves, boosts etc.
- copies of the conversation trees of all your toots, including stats like faves, boosts etc. as well as attached files for each message
- all files you've ever attached to toots
- your settings
- your filters
- your mutes
- your blocks
- your server blocks
- etc.
Change your login
Also, your login will have to change from short name + passphrase to e-mail + passphrase. Your short name is part of your identity, it's in the container, it will be cloned, so it can't be used to log you in anymore.
In order for this to work, half of Mastodon's server backend will have to be rewritten.Decentralised IDs
Next, Mastodon must switch from the Webfinger IDs that it uses now to decentralised IDs as per FEP-ef61. For a while, I guess, it will have to use both next to one another. Then it will have to phase out its Webfinger IDs.
The decentralised IDs must be tested against other Fediverse software that already understands them or that's nomadic itself: (streams), Forte, Mitra, Tootik. For example, @silverpill of Mitra and @Mike Macgirvin of (streams) and Forte must test whether their software correctly understands Mastodon's DIDs. And the Mastodon developers must test whether Mastodon correctly understands the DIDs from Fediverse server applications that already use them.
Once it has gotten rid of its Webfinger IDs, the next phase can start.Implement cloning within Mastodon
The central element of nomadic identity is not the ability to move your identity. That's only a byproduct of cloning your identity.
A clone, in nomadic identity, is a full backup of the container with your identity in it. A real-time, live, bidirectional backup that you can log into and use just like the "original". The clone always has the same idea as the original, regardless of which server it's on.
The key elements of clones and cloning must be implemented and tested:- cloning an identity container to a different server after registering a new, blank account there
- cloning an identity container to a different server where you already have an account with a different containerised identity
- anything that happens on the original being sync'd to the clone
- anything that happens on the clone being sync'd to the original
- clone going offline, things happening on the original, clone coming back online, things that happened on the original being reliably sync'd to the clone
- original going offline, clone still working with the ID based on the original's domain
- original going offline, things happening on the clone, original coming back online, things that happened on the clone being reliably sync'd to the original
- making additional clones of an identity container that has already been cloned at least once
- the whole syncing shebang from the original to any number of clones
- the whole syncing shebang from one of the clones to the original and also directly to the other clones
- declaring one of the clones the new original, thus changing the ID of both the former original and all clones
Implement moving within Mastodon
Only when cloning works reliably, we can talk about moving, even though that's what everyone on Mastodon is giddy about.
Why? Because moving involves cloning. It's an automated process. At least it is on Hubzilla, (streams) and Forte, and it really should be one on nomadic Mastodon.
Basically, first you make a clone.
Then you declare the clone the new original, and your old original is demoted to a clone.
Then you have to wait until your change of ID from changing the original has federated to all your followers and followed and everywhere and whatnot.
Then, one last sync so that both the former-clone-now-new-original and the old-original-now-clone are really identical, and you won't lose any data.
Then your old-original-now-clone is deleted. We don't want to leave any dead stuff behind, now, do we?
Lastly, if your old account where your old original used to reside has no other identity on it, the whole account is deleted. In nomadic containerised identity, accounts cannot/should not exist with no identity container on them.Cloning and moving beyond Mastodon
The last possible step is still utter science-fiction: Cloning or moving from Mastodon to something else that's nomadic and understands FEP-ef61.
Cloning or moving from Mastodon to Mitra. From Mastodon to Tootik. From Mastodon to (streams). From Mastodon to Forte. Oh, and maybe also back to Mastodon.
The difficult part is not only to make Mastodon capable of cloning identity containers to other nomadic software. And to make Mastodon accept identity containers from other nomadic software being cloned to Mastodon. I mean, this would be difficult already. (streams) and Forte are vastly, vastly different from Mastodon.
No, the difficult part is to make these four capable of cloning from or to someplace else. As it stands now, you can only clone from Mitra to Mitra, from Tootik to Tootik, from (streams) to (streams), from Forte to Forte. Even cloning between (streams) and Forte has never been possible, even though they're very similar. Oh, and cloning from and to Hubzilla is another story because Hubzilla doesn't have FEP-ef61 implemented.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #Tootik #NomadicIdentity -
@Patrick Leavy A whole lot. Sorry, but this will be very very very long again.
I don't know if you've read my previous (very long) commentary. But just implementing one or two FEPs won't get you the same full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) that Hubzilla (what I'm writing from right now; https://hubzilla.org; https://en.wikipedia.org/wiki/Hubzilla; https://joinfediverse.wiki/Hubzilla) has had since 2012. And having this level of nomadic identity has to be the goal.
What has to be done is:
Take something like Mastodon.
Non-nomadic.
Where your account, your login, equals your identity.Make your identity cloneable
Now, before you can make identities nomadic, you have to uncouple them from the login, from the account.
Mastodon has to introduce a sort of container for your identity, like the channels that Hubzilla, (streams) and Forte have always had (https://joinfediverse.wiki/Channels_(Hubzilla_&_(streams))). This is necessary so that a future nomadic Mastodon will know what to clone and what not to clone. For example, cloning your password is dangerous nonsense.
So, everything that makes up your account except for your login credentials will have to be moved into this container.- your short name
- your long name
- your profile images, including alt-texts
- your profile
- your followers
- your followed
- your toots, including stats like faves, boosts etc.
- copies of the conversation trees of all your toots, including stats like faves, boosts etc. as well as attached files for each message
- all files you've ever attached to toots
- your settings
- your filters
- your mutes
- your blocks
- your server blocks
- etc.
Change your login
Also, your login will have to change from short name + passphrase to e-mail + passphrase. Your short name is part of your identity, it's in the container, it will be cloned, so it can't be used to log you in anymore.
In order for this to work, half of Mastodon's server backend will have to be rewritten.Decentralised IDs
Next, Mastodon must switch from the Webfinger IDs that it uses now to decentralised IDs as per FEP-ef61. For a while, I guess, it will have to use both next to one another. Then it will have to phase out its Webfinger IDs.
The decentralised IDs must be tested against other Fediverse software that already understands them or that's nomadic itself: (streams), Forte, Mitra, Tootik. For example, @silverpill of Mitra and @Mike Macgirvin of (streams) and Forte must test whether their software correctly understands Mastodon's DIDs. And the Mastodon developers must test whether Mastodon correctly understands the DIDs from Fediverse server applications that already use them.
Once it has gotten rid of its Webfinger IDs, the next phase can start.Implement cloning within Mastodon
The central element of nomadic identity is not the ability to move your identity. That's only a byproduct of cloning your identity.
A clone, in nomadic identity, is a full backup of the container with your identity in it. A real-time, live, bidirectional backup that you can log into and use just like the "original". The clone always has the same idea as the original, regardless of which server it's on.
The key elements of clones and cloning must be implemented and tested:- cloning an identity container to a different server after registering a new, blank account there
- cloning an identity container to a different server where you already have an account with a different containerised identity
- anything that happens on the original being sync'd to the clone
- anything that happens on the clone being sync'd to the original
- clone going offline, things happening on the original, clone coming back online, things that happened on the original being reliably sync'd to the clone
- original going offline, clone still working with the ID based on the original's domain
- original going offline, things happening on the clone, original coming back online, things that happened on the clone being reliably sync'd to the original
- making additional clones of an identity container that has already been cloned at least once
- the whole syncing shebang from the original to any number of clones
- the whole syncing shebang from one of the clones to the original and also directly to the other clones
- declaring one of the clones the new original, thus changing the ID of both the former original and all clones
Implement moving within Mastodon
Only when cloning works reliably, we can talk about moving, even though that's what everyone on Mastodon is giddy about.
Why? Because moving involves cloning. It's an automated process. At least it is on Hubzilla, (streams) and Forte, and it really should be one on nomadic Mastodon.
Basically, first you make a clone.
Then you declare the clone the new original, and your old original is demoted to a clone.
Then you have to wait until your change of ID from changing the original has federated to all your followers and followed and everywhere and whatnot.
Then, one last sync so that both the former-clone-now-new-original and the old-original-now-clone are really identical, and you won't lose any data.
Then your old-original-now-clone is deleted. We don't want to leave any dead stuff behind, now, do we?
Lastly, if your old account where your old original used to reside has no other identity on it, the whole account is deleted. In nomadic containerised identity, accounts cannot/should not exist with no identity container on them.Cloning and moving beyond Mastodon
The last possible step is still utter science-fiction: Cloning or moving from Mastodon to something else that's nomadic and understands FEP-ef61.
Cloning or moving from Mastodon to Mitra. From Mastodon to Tootik. From Mastodon to (streams). From Mastodon to Forte. Oh, and maybe also back to Mastodon.
The difficult part is not only to make Mastodon capable of cloning identity containers to other nomadic software. And to make Mastodon accept identity containers from other nomadic software being cloned to Mastodon. I mean, this would be difficult already. (streams) and Forte are vastly, vastly different from Mastodon.
No, the difficult part is to make these four capable of cloning from or to someplace else. As it stands now, you can only clone from Mitra to Mitra, from Tootik to Tootik, from (streams) to (streams), from Forte to Forte. Even cloning between (streams) and Forte has never been possible, even though they're very similar. Oh, and cloning from and to Hubzilla is another story because Hubzilla doesn't have FEP-ef61 implemented.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #Tootik #NomadicIdentity -
@Patrick Leavy
Is the #ActivityPub protocol any closer to having data portability?
Have you read about nomadic identity yet? (https://joinfediverse.wiki/Nomadic_identity)
There is only one Fediverse server application that offers full-blown server-side nomadic identity via ActivityPub, and that's Forte (https://codeberg.org/fortified/forte). This won't change anytime soon. For there is one critically important thing that has never happened yet, and that's the conversion of non-nomadic, account-equals-identity, ActivityPub-based Fediverse software to fully nomadic, identity-uncoupled-from-accounts, ActivityPub-based Fediverse software.
Forte itself came to exist in 2024 as a fork of something colloquially called (streams) which is already nomadic, but based on its own protocol named Nomad with ActivityPub as an optional secondary protocol. And (streams) is a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, the first nomadic Fediverse software, created in 2012 under the name Red and based on a precursor of Nomad.
A very long-term dream is a fully nomadic Fediverse. Not only would all Fediverse server software be every bit as nomadic as Hubzilla, but it'd be possible to move and even clone identities between different server applications. As it stands now, moving and cloning is only possible within Hubzilla, within (streams) and within Forte.And how about single ID usable in different apps?
This would only be possible in an entirely nomadic Fediverse where you can clone your identity from anywhere to anywhere. And even then you'd have to first register a local account on whichever server you want to use and then clone your existing identity onto this account on this server.
Otherwise, this is not possible. And it isn't possible at all without registering a local account on whichever server you want to create.
I mean, I've read this request countless times.- Create an account on mastodon.social.
- Go to peertube.tv.
- Log onto peertube.tv with your mastodon.social credentials. Right away. Without first creating an account on peertube.tv.
- Upload a video credited to [email protected].
There are lots of reasons why this is technologically impossible.
First of all: Where would peertube.tv know your mastodon.social login credentials from? Your name and at least the salted hash of your passphrase?
Besides: Where would peertube.tv store your data?
On mastodon.social where your account is?
And, pray tell, where would mastodon.social store a video the same way as PeerTube stores it, all the way to PeerTube's trademark peer-to-peer load balancing? Also, how and why do you think should mastodon.social authorise peertube.tv to directly, remotely write to mastodon.social's local database and data storage?
On peertube.tv?
Well, that'd require peertube.tv to have a record of your identity in its local database. It can't store a video locally. and reference it locally through mastodon.social's local database. So peertube.tv's server backend would have to know you. It would have to have your identity.
Where would it get that?
Again, no, it can't just simply reference mastodon.social's database for that. It'd need that record in its own local database.
Do you really believe that peertube.tv could go and leech all your account credentials from mastodon.social and automagically store them locally? Do you really believe mastodon.social will let it do that?
And do you seriously believe that if free, open-source, amateur-developed server software can easily do that, proprietary, closed-source, professional, military-intelligence-grade (as in FBI, DHS, CIA, NSA, STRATFOR, MI5, MI6, Mossad, Shin Bet), ultra-high-end espionage and surveillance software like Palantir or NSO Pegasus has no way at all of doing that?
No, there's literally only one possible way for peertube.tv to get to know you and know whom this video belongs to if you upload one. And that's by you registering a local account on peertube.tv. Manually.
Okay, now you (or someone else) may come and say, "But Pixelfed can literally do that! I can log onto Pixelfed with my Mastodon account!"
No. No, you can't. Sorry to say, but you can't.
Pixelfed pretends you can. For the sake of convenience and ease-of-use. But it's bogus. All show. A smoke screen.
What Pixelfed actually does when you "log into it with your Mastodon account": It takes your Mastodon login name, it takes your Mastodon passphrase, and it registers a local account on that Pixelfed server with your Mastodon login credentials.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #PeerTube #Pixelfed #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@Patrick Leavy
Is the #ActivityPub protocol any closer to having data portability?
Have you read about nomadic identity yet? (https://joinfediverse.wiki/Nomadic_identity)
There is only one Fediverse server application that offers full-blown server-side nomadic identity via ActivityPub, and that's Forte (https://codeberg.org/fortified/forte). This won't change anytime soon. For there is one critically important thing that has never happened yet, and that's the conversion of non-nomadic, account-equals-identity, ActivityPub-based Fediverse software to fully nomadic, identity-uncoupled-from-accounts, ActivityPub-based Fediverse software.
Forte itself came to exist in 2024 as a fork of something colloquially called (streams) which is already nomadic, but based on its own protocol named Nomad with ActivityPub as an optional secondary protocol. And (streams) is a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, the first nomadic Fediverse software, created in 2012 under the name Red and based on a precursor of Nomad.
A very long-term dream is a fully nomadic Fediverse. Not only would all Fediverse server software be every bit as nomadic as Hubzilla, but it'd be possible to move and even clone identities between different server applications. As it stands now, moving and cloning is only possible within Hubzilla, within (streams) and within Forte.And how about single ID usable in different apps?
This would only be possible in an entirely nomadic Fediverse where you can clone your identity from anywhere to anywhere. And even then you'd have to first register a local account on whichever server you want to use and then clone your existing identity onto this account on this server.
Otherwise, this is not possible. And it isn't possible at all without registering a local account on whichever server you want to create.
I mean, I've read this request countless times.- Create an account on mastodon.social.
- Go to peertube.tv.
- Log onto peertube.tv with your mastodon.social credentials. Right away. Without first creating an account on peertube.tv.
- Upload a video credited to [email protected].
There are lots of reasons why this is technologically impossible.
First of all: Where would peertube.tv know your mastodon.social login credentials from? Your name and at least the salted hash of your passphrase?
Besides: Where would peertube.tv store your data?
On mastodon.social where your account is?
And, pray tell, where would mastodon.social store a video the same way as PeerTube stores it, all the way to PeerTube's trademark peer-to-peer load balancing? Also, how and why do you think should mastodon.social authorise peertube.tv to directly, remotely write to mastodon.social's local database and data storage?
On peertube.tv?
Well, that'd require peertube.tv to have a record of your identity in its local database. It can't store a video locally. and reference it locally through mastodon.social's local database. So peertube.tv's server backend would have to know you. It would have to have your identity.
Where would it get that?
Again, no, it can't just simply reference mastodon.social's database for that. It'd need that record in its own local database.
Do you really believe that peertube.tv could go and leech all your account credentials from mastodon.social and automagically store them locally? Do you really believe mastodon.social will let it do that?
And do you seriously believe that if free, open-source, amateur-developed server software can easily do that, proprietary, closed-source, professional, military-intelligence-grade (as in FBI, DHS, CIA, NSA, STRATFOR, MI5, MI6, Mossad, Shin Bet), ultra-high-end espionage and surveillance software like Palantir or NSO Pegasus has no way at all of doing that?
No, there's literally only one possible way for peertube.tv to get to know you and know whom this video belongs to if you upload one. And that's by you registering a local account on peertube.tv. Manually.
Okay, now you (or someone else) may come and say, "But Pixelfed can literally do that! I can log onto Pixelfed with my Mastodon account!"
No. No, you can't. Sorry to say, but you can't.
Pixelfed pretends you can. For the sake of convenience and ease-of-use. But it's bogus. All show. A smoke screen.
What Pixelfed actually does when you "log into it with your Mastodon account": It takes your Mastodon login name, it takes your Mastodon passphrase, and it registers a local account on that Pixelfed server with your Mastodon login credentials.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #PeerTube #Pixelfed #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@Patrick Leavy
Is the #ActivityPub protocol any closer to having data portability?
Have you read about nomadic identity yet? (https://joinfediverse.wiki/Nomadic_identity)
There is only one Fediverse server application that offers full-blown server-side nomadic identity via ActivityPub, and that's Forte (https://codeberg.org/fortified/forte). This won't change anytime soon. For there is one critically important thing that has never happened yet, and that's the conversion of non-nomadic, account-equals-identity, ActivityPub-based Fediverse software to fully nomadic, identity-uncoupled-from-accounts, ActivityPub-based Fediverse software.
Forte itself came to exist in 2024 as a fork of something colloquially called (streams) which is already nomadic, but based on its own protocol named Nomad with ActivityPub as an optional secondary protocol. And (streams) is a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, the first nomadic Fediverse software, created in 2012 under the name Red and based on a precursor of Nomad.
A very long-term dream is a fully nomadic Fediverse. Not only would all Fediverse server software be every bit as nomadic as Hubzilla, but it'd be possible to move and even clone identities between different server applications. As it stands now, moving and cloning is only possible within Hubzilla, within (streams) and within Forte.And how about single ID usable in different apps?
This would only be possible in an entirely nomadic Fediverse where you can clone your identity from anywhere to anywhere. And even then you'd have to first register a local account on whichever server you want to use and then clone your existing identity onto this account on this server.
Otherwise, this is not possible. And it isn't possible at all without registering a local account on whichever server you want to create.
I mean, I've read this request countless times.- Create an account on mastodon.social.
- Go to peertube.tv.
- Log onto peertube.tv with your mastodon.social credentials. Right away. Without first creating an account on peertube.tv.
- Upload a video credited to [email protected].
There are lots of reasons why this is technologically impossible.
First of all: Where would peertube.tv know your mastodon.social login credentials from? Your name and at least the salted hash of your passphrase?
Besides: Where would peertube.tv store your data?
On mastodon.social where your account is?
And, pray tell, where would mastodon.social store a video the same way as PeerTube stores it, all the way to PeerTube's trademark peer-to-peer load balancing? Also, how and why do you think should mastodon.social authorise peertube.tv to directly, remotely write to mastodon.social's local database and data storage?
On peertube.tv?
Well, that'd require peertube.tv to have a record of your identity in its local database. It can't store a video locally. and reference it locally through mastodon.social's local database. So peertube.tv's server backend would have to know you. It would have to have your identity.
Where would it get that?
Again, no, it can't just simply reference mastodon.social's database for that. It'd need that record in its own local database.
Do you really believe that peertube.tv could go and leech all your account credentials from mastodon.social and automagically store them locally? Do you really believe mastodon.social will let it do that?
And do you seriously believe that if free, open-source, amateur-developed server software can easily do that, proprietary, closed-source, professional, military-intelligence-grade (as in FBI, DHS, CIA, NSA, STRATFOR, MI5, MI6, Mossad, Shin Bet), ultra-high-end espionage and surveillance software like Palantir or NSO Pegasus has no way at all of doing that?
No, there's literally only one possible way for peertube.tv to get to know you and know whom this video belongs to if you upload one. And that's by you registering a local account on peertube.tv. Manually.
Okay, now you (or someone else) may come and say, "But Pixelfed can literally do that! I can log onto Pixelfed with my Mastodon account!"
No. No, you can't. Sorry to say, but you can't.
Pixelfed pretends you can. For the sake of convenience and ease-of-use. But it's bogus. All show. A smoke screen.
What Pixelfed actually does when you "log into it with your Mastodon account": It takes your Mastodon login name, it takes your Mastodon passphrase, and it registers a local account on that Pixelfed server with your Mastodon login credentials.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #PeerTube #Pixelfed #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@Patrick Leavy
Is the #ActivityPub protocol any closer to having data portability?
Have you read about nomadic identity yet? (https://joinfediverse.wiki/Nomadic_identity)
There is only one Fediverse server application that offers full-blown server-side nomadic identity via ActivityPub, and that's Forte (https://codeberg.org/fortified/forte). This won't change anytime soon. For there is one critically important thing that has never happened yet, and that's the conversion of non-nomadic, account-equals-identity, ActivityPub-based Fediverse software to fully nomadic, identity-uncoupled-from-accounts, ActivityPub-based Fediverse software.
Forte itself came to exist in 2024 as a fork of something colloquially called (streams) which is already nomadic, but based on its own protocol named Nomad with ActivityPub as an optional secondary protocol. And (streams) is a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, the first nomadic Fediverse software, created in 2012 under the name Red and based on a precursor of Nomad.
A very long-term dream is a fully nomadic Fediverse. Not only would all Fediverse server software be every bit as nomadic as Hubzilla, but it'd be possible to move and even clone identities between different server applications. As it stands now, moving and cloning is only possible within Hubzilla, within (streams) and within Forte.And how about single ID usable in different apps?
This would only be possible in an entirely nomadic Fediverse where you can clone your identity from anywhere to anywhere. And even then you'd have to first register a local account on whichever server you want to use and then clone your existing identity onto this account on this server.
Otherwise, this is not possible. And it isn't possible at all without registering a local account on whichever server you want to create.
I mean, I've read this request countless times.- Create an account on mastodon.social.
- Go to peertube.tv.
- Log onto peertube.tv with your mastodon.social credentials. Right away. Without first creating an account on peertube.tv.
- Upload a video credited to [email protected].
There are lots of reasons why this is technologically impossible.
First of all: Where would peertube.tv know your mastodon.social login credentials from? Your name and at least the salted hash of your passphrase?
Besides: Where would peertube.tv store your data?
On mastodon.social where your account is?
And, pray tell, where would mastodon.social store a video the same way as PeerTube stores it, all the way to PeerTube's trademark peer-to-peer load balancing? Also, how and why do you think should mastodon.social authorise peertube.tv to directly, remotely write to mastodon.social's local database and data storage?
On peertube.tv?
Well, that'd require peertube.tv to have a record of your identity in its local database. It can't store a video locally. and reference it locally through mastodon.social's local database. So peertube.tv's server backend would have to know you. It would have to have your identity.
Where would it get that?
Again, no, it can't just simply reference mastodon.social's database for that. It'd need that record in its own local database.
Do you really believe that peertube.tv could go and leech all your account credentials from mastodon.social and automagically store them locally? Do you really believe mastodon.social will let it do that?
And do you seriously believe that if free, open-source, amateur-developed server software can easily do that, proprietary, closed-source, professional, military-intelligence-grade (as in FBI, DHS, CIA, NSA, STRATFOR, MI5, MI6, Mossad, Shin Bet), ultra-high-end espionage and surveillance software like Palantir or NSO Pegasus has no way at all of doing that?
No, there's literally only one possible way for peertube.tv to get to know you and know whom this video belongs to if you upload one. And that's by you registering a local account on peertube.tv. Manually.
Okay, now you (or someone else) may come and say, "But Pixelfed can literally do that! I can log onto Pixelfed with my Mastodon account!"
No. No, you can't. Sorry to say, but you can't.
Pixelfed pretends you can. For the sake of convenience and ease-of-use. But it's bogus. All show. A smoke screen.
What Pixelfed actually does when you "log into it with your Mastodon account": It takes your Mastodon login name, it takes your Mastodon passphrase, and it registers a local account on that Pixelfed server with your Mastodon login credentials.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #PeerTube #Pixelfed #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@Patrick Leavy
Is the #ActivityPub protocol any closer to having data portability?
Have you read about nomadic identity yet? (https://joinfediverse.wiki/Nomadic_identity)
There is only one Fediverse server application that offers full-blown server-side nomadic identity via ActivityPub, and that's Forte (https://codeberg.org/fortified/forte). This won't change anytime soon. For there is one critically important thing that has never happened yet, and that's the conversion of non-nomadic, account-equals-identity, ActivityPub-based Fediverse software to fully nomadic, identity-uncoupled-from-accounts, ActivityPub-based Fediverse software.
Forte itself came to exist in 2024 as a fork of something colloquially called (streams) which is already nomadic, but based on its own protocol named Nomad with ActivityPub as an optional secondary protocol. And (streams) is a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, the first nomadic Fediverse software, created in 2012 under the name Red and based on a precursor of Nomad.
A very long-term dream is a fully nomadic Fediverse. Not only would all Fediverse server software be every bit as nomadic as Hubzilla, but it'd be possible to move and even clone identities between different server applications. As it stands now, moving and cloning is only possible within Hubzilla, within (streams) and within Forte.And how about single ID usable in different apps?
This would only be possible in an entirely nomadic Fediverse where you can clone your identity from anywhere to anywhere. And even then you'd have to first register a local account on whichever server you want to use and then clone your existing identity onto this account on this server.
Otherwise, this is not possible. And it isn't possible at all without registering a local account on whichever server you want to create.
I mean, I've read this request countless times.- Create an account on mastodon.social.
- Go to peertube.tv.
- Log onto peertube.tv with your mastodon.social credentials. Right away. Without first creating an account on peertube.tv.
- Upload a video credited to [email protected].
There are lots of reasons why this is technologically impossible.
First of all: Where would peertube.tv know your mastodon.social login credentials from? Your name and at least the salted hash of your passphrase?
Besides: Where would peertube.tv store your data?
On mastodon.social where your account is?
And, pray tell, where would mastodon.social store a video the same way as PeerTube stores it, all the way to PeerTube's trademark peer-to-peer load balancing? Also, how and why do you think should mastodon.social authorise peertube.tv to directly, remotely write to mastodon.social's local database and data storage?
On peertube.tv?
Well, that'd require peertube.tv to have a record of your identity in its local database. It can't store a video locally. and reference it locally through mastodon.social's local database. So peertube.tv's server backend would have to know you. It would have to have your identity.
Where would it get that?
Again, no, it can't just simply reference mastodon.social's database for that. It'd need that record in its own local database.
Do you really believe that peertube.tv could go and leech all your account credentials from mastodon.social and automagically store them locally? Do you really believe mastodon.social will let it do that?
And do you seriously believe that if free, open-source, amateur-developed server software can easily do that, proprietary, closed-source, professional, military-intelligence-grade (as in FBI, DHS, CIA, NSA, STRATFOR, MI5, MI6, Mossad, Shin Bet), ultra-high-end espionage and surveillance software like Palantir or NSO Pegasus has no way at all of doing that?
No, there's literally only one possible way for peertube.tv to get to know you and know whom this video belongs to if you upload one. And that's by you registering a local account on peertube.tv. Manually.
Okay, now you (or someone else) may come and say, "But Pixelfed can literally do that! I can log onto Pixelfed with my Mastodon account!"
No. No, you can't. Sorry to say, but you can't.
Pixelfed pretends you can. For the sake of convenience and ease-of-use. But it's bogus. All show. A smoke screen.
What Pixelfed actually does when you "log into it with your Mastodon account": It takes your Mastodon login name, it takes your Mastodon passphrase, and it registers a local account on that Pixelfed server with your Mastodon login credentials.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #PeerTube #Pixelfed #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883
I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.
No, there are 3 options:
- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini
-
Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883
I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.
No, there are 3 options:
- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini
-
Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883
I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.
No, there are 3 options:
- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini
-
Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883
I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.
No, there are 3 options:
- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini
-
An idea or concept for local-first blogging thingy
Reblog via Jeremiah Lee
The opposite of cloud computing is LEAF computing:
Local application logic and data
End-to-end encrypted data
Autonomous operation without non-optional dependencies
Federated capability between devices and connectivity with trusted partiesI seen this thanks to boost from Elena Rossini FOSDEM blog.
And this happened exactly when I thought about moving away from wordpress to something completely different. But this different thing, suddenly, does not exist at all yet. Or at least I do not know about its existence.
I will be as brief as possible. Imagine a blogging software with these traits:
Local-First
You have full copy of all your posts, media files, and even videos locally. Even the feed of authors you follow is fully local to most possible extent. You can read locally without internet, write replies and place reactions to them locally, even without the internet connection active.
Minimal network footprint
All what is necessary to keep it online is to connect sometimes, like 1-2 times per day or once per few days (but with larger packs of data to exchange) to a minimalistic online data pod.
This online data pod would consist of static pages generated from the posts, which would have some minimally interactive “islands” like comments section or reactions panel,
printbutton or some other pieces like images gallery or advanced image widget if used, with fallback to bare minimum thing if your reader disabled the JavaScript at all.The small backend purpose would be to accept incoming data via ActivityPub, WebMentions, SMTP, Git, or other possible means, and spread data to your followers with a job.
It would generate static pages from arriving your posts or regenerate them if related post have been updated.
From ActivityPub perspective the private messages would arrive to different inbox.
End-to-end encryption where applicable
Your data on this pod would be criptographically protected/signed but not encrypted by default (unless if this piece of data have been arrived in encrypted form to be encrypted by the sender (by you or some of your respondents).
Simple online storage at core
The core function of online data pod is to generate static pages from the arriving posts and media, serve it, spread updates to followers, and collect incoming reactions and replies.
Mostly it would consist of following parts:
- Static Files skin (layout, templates, styles, images)
- Generated pages and media (served as static but updated on changes)
- Signed data bucket (can be a simple set of files and directories but without direct public access, no database mandatory). You can set expiration age on any of your posts or messages.
- Arriving Data Cache (reactions, replies, data from followed authors). Can be implemented as another private directory. Cleared either as soon as downloaded to you or after reaching some age, such as 1 day or week.
- Jobs runner (spread updates to your followers, delete expired data).
- Data receptors (SMTP, IMAP, FTP, API requests handlers for ActivityPub and WebMentions, API handlers for interactive islands like comments and reactions section).
- Minimal metadata database built based on files from directores listed above where necessary and to keep state for jobs runner. Can be implemented as set of JSON files and special module with in-memory indexes and in-process API similar to how JSDB works. Used only where JSON files are not enough or be too slow/ineffective.
Most of these elements, you can notice, would work with 3-4 directories of files, like:
- long-term static. Public read-only access. never change after online data pod started
- Public generated static – public read-only access. can change while pod. Generated based on posts data and other events.
- Private protected data – private data that most of the time is readonly unless you edit it or delete from the editor and send the update.
- Arriving data – private data temporary stored until expire or until downloaded, or until processed by jobs runner, depending on what kind of data it is – your updates and new posts or it is
- Departing data – private data temporary stored until delivered or until become clear data delivery impossible and decision made to not delivery that data.
- Jobs runner states – private data used for scheduled jobs.
Connectivity hub and jobs runner
This is the place that goes beyond files storing. Ideally it would be something that can handle SFTP, IMAP, SMTP, and these HTTP API endpoints for ActivityPub and WebMentions necessary for federation part. This, to significant part, is why ever it can not be done via pure SFTP or IMAP or SMTP part.
Nomadic identity
I guess this is where it may be the most boring part of this, with all these digital signatures, authentication, and so on. Mostly it is about binding signing key to digital identity such as author or blog or organization or service. It is simply to say that:
- Use this public key to check whether
[email protected]nickname is author of posthttps://foo.bar.online/AliceCooks/Pancakes - Check with this (other?) key whether given direct message is from
[email protected] - Use this (third?) key to encrypt messages to the
[email protected]sent via SMTP (or ActivityPub?) - Public profile card details such as Alice The Space Cook title, profile pic, card background imagery, description, tags, topic spaces (labels from tree-like catalog like
alt.hobbbies.home.cookingand alike. - Previous key and signature (optional if this is not about changing the key)
- Digital signature of all this above with the first key from listed above.
- Endorsements – list of digital signatures with such cards from people who endorse (express their trust) to the claims above).
Note that all data is included into these cards, all images, descriptions, URLs, tags, and spaces is embedded. So card with endorsements can be quite big, up to 1 megabyte. But it is better than somehow store that at some centralized catalogue.
What really makes this identity nomadic is the fact you can multiple online pods or connectivity hubs storing your data or hop from one such hub to another together with your followers and contacts lists stored locally too.
Contacts and followers
The system of such cards described above would work even without classic DNS, but based on GnuNet GNS or local catalogue of “internet phone numbers” described by Aral Balkan in mentioned his post.
Daily Newspaper instead of endless feed
Instead of endless feed that causes intentional or unintentional doom scrolling, I would suggest to use locally-running code that would create using data downloaded from the online pod(s) a sort of “daily newspapers”, lets call it like “News for Breakfast”, “Evening Observer”, or “Climate Express” or “Solarpunk Tribune” or “Hightech news bulletin”. It is possible to create multiple various such newspapers working on your local data (what arrived during some timeframe) in various style. Some of these “newspapers” can include some global stuff, or use some global trending things, but this should be absolutely optional, and provided by following the related author which would provide such manually picked global news data or global topics or events and classification settings or both. Each of that would be separate offerings.
The whole such experience should be fully available locally, without connection to the internet, as soon as all related data downloaded.
Imagine if you open the app (at desktop or laptop!) and see two tables. One have Newspapers sign and looks exactly as the table with stack of newspapers. You pick one of them, and it opens in a way resembling the newspaper, with the front page content, and the rest content cut into pages. Of course the resemblance of newspaper is limited, and if you want, you can open the post(s) mentioned in the newspaper text or used to produce it.
The other table would look like a table with a pile of letters, you open in more or less letter-like experience, or that experience can be just a “boring email-like client” or something more like “messenger-like” experience or something between, but with letting people know it is NOT designed for chat-like instant messengers experience.
At a Glance
Together this may look as something not very powerful, as many people today assume that any software aiming to be “successful” or “widespread” should have audio-video calls and instant messaging features.
Capabilities
The software I describing is mostly centered around these capabilities intentionally:
- public long read posts with formatting and attached media and cached embeds for links.
- Public reactions, comments and reposts
- Private messages with e2ee capabilities
- Contacts card collection, exchange and endorsement
- Daily newspaper-like thing instead of “feed-like” experience
Big parts
These 2 completely different parts are necessary:
- Local-first desktop software (blog editor based on Markdown full support (including sanitized html blocks and CSS for advanced formatting), messages a-la mix of email and asynchronous chat, and contacts cards library)
- Online data pod that would work as public data point and node for the system. Multiple pods can be used by same person. It should use as basic and widespread protocols as possible, such as SFTP, SMTP, and IMAP, and open standards as ActivityPub, WebMentions, WebIntents.
Moderation and abuse reporting not covered, but doable
This idea does not cover such aspects as moderation, abuse reporting, or preventing local abuse.
Regarding local abuse like relatives opening your PC without your pemission. It is terrible thing even to mention, while I personally I did not experience anything like that. I just remember some blog post describing these treats and related problems. Software for these kinds of treats model surely completely different and needs another set of capabilities like “delete all password”, “fake/safe data” credentials, and even local data should be encrypted similar to how Aegis 2FA OTP manager or some SimpleXChat messenger clients stores their database and require to type password to open the database.
Regarding moderation abuse reporting, situation is more complicated. To significant extent, the moderation can be done locally with various tools such as blocklists/mute lists, and regarding abuse reporting, it mostly about contact de-endorsement via some high-trusted third-party, who has been chosen by person who report abuse as moderator.
As the online data pods can be run by anyone, and not necessary it would be some mass service for such pods, it can be complicated to really “block” someone. De-endorsement would have strong effect, if moderator chosen by many or trusted by many (like “I may not use moderation services by Foo Bar, but I will accept de-endorsements” they may issue.
De-endorsements are public and special kind of posts.
Endorsements can be private in sense that such endorsement issued about one contact A for another B by a contact C and only C and C know about that. Or they can be public, with special kind of post.
Endorsement and de-endorsement posts are consists of contact cards being endorsed and de-endorsed.
Blocklists can be about contact cards (specific digital identity), or about online data pods (same as domain block or de-federate in Mastodon), spaces or tags or mix of these above. Technically blocklists are public blogs following special formatting.
Moderation labels can be applied to the contacts and posts by moderators which are more like labeling, and it not necessary means muting or blocking or de-endorsement, but for some of moderation labels it can mean de-endorsement. For example if you are a moderator and place moderation label
disinformationon post or account, this is not same as placing tagdisinformationon blog post debunking some disinformation or exposing another propaganda network.Still, due local-first nature of the project, the actual moderation can happen only locally, except for case when you follow some blocklist or do not want to see content labeled as
sex and pornorviolenceby moderators or even having tag (not moderation label but tag)nsfwyou can update your online data pod to silently ignore such data on arrival, so it even would not be saved at pod, and will not be arrived into local data as well.Following a moderation posts blog and expressing related level of trust (“I will use this blocklist and that labeling service”) at local settings and online data pod configuration is single way to implement moderation for local-first project.
Questions and Examples on Newspaper format
Is there a way to make such “newspapers generator” without LLMs? Are there more specialized algorithms for tasks like that? To take various posts sequence for some time interval, or multiple such sequences, mix with global events definition list, and produce newspaper-like format, consisting of some pages of text and images, sorted by priority, to be sure the most important go to first few screens? Or without sorting but just with grouping?
I would like to avoid LLMs, even locally running, for feature like that.
For global news, such newspaper can be human made like how the Civil.ge newsletter Morning Cable works.
But what is alternative to LLMs if make this kind of “newspaper” in more or less automated way? Like…
Today SuperSun writes about upcycling practices in solarpunk community Optimistic Valley and describes how abandoned warehouse become a creative recreational and living space for the community and what the struggle it was to get all necessary permits from local council.
19 people commented this and expressed 128 reactions. The most surprising was disbelief expressed by CringyPunk what caused notable responses both from SuperSun (author) and BringingSunHere
Or another type of thing what can land in the “Newspaper” regarding global news:
The latest Russian strikes against Ukrainian civilians caused widespread condemnation and widespread criticism from your contacts. Some authors you follow try to use satire and humor to cope with the horror of war and another wave of destruction and death. It works partly because such strikes does not help Russian genocidal empire to reach their military objectives, ISW notes. Quite opposite. Also, more EU and US sanctions to come in response.
And third example for such newspaper blocks:
The ongoing football world cup event sparked lot of emotions from your contacts. 10 of people you follow expressed joy on catastrophic loss of US team to Belgium with 4-1 scores while BoringSceptic wrote a grumpy longread on how the big sport funnels private and public money away from top priorities and used solely for propaganda by the dictatorships for decades.
These are random examples of how these blocks in newspaper-like stuff would like.
Online Pod services
Even with all these tutorials floating around about self-hosting and blog about Elena Rossini Sudo Life covering her fascinating self-hosting adventures, not everyone have time to self-host, and if we would like to land more people to platform like what I described, it would require some online data pod service, like hosting service running analog of Domain software for kitten by Aral Balkan.
It is likely that some of such services could be a paid ones, others would try to cover up expenses with donations via Patreon and other ways.
Other such services can use one-time entry payment instead of regular payments just to protect self from spam and disinfo bots.
Limitations
The project is not about total anonymity or full-blown censorship resistance.
Some of well-trusted endorcers may use video call where you would speak with them and show your id card or something like that to check you are surely not a bot or ensure that you are really who you claim to be. But not every endorsement would come from such service.
The project does not require to use some advanced protocols or tech like Tor for anonymization or I2P or other peer-to-peer connectivity for directly connecting with your authors.
The whole idea of online data pods is a way to overcome the fact that internet is a set of pyramids, such as SSL certificates tree, DNS system is based on centralized names tree prune to censorship and attacks, that is why it is pure optional for this system to work. And the whole IP addresses space is non-uniform – so called residential IP addresses are restricted or second-class citizens, as it often happens with SMTP due spam flood happening with email.
The project intentionally avoid use cases which require instant messaging capabilities or real-time connectivity like audio-video calls. The whole idea of this project is to create environment encouraging you to making reading of news some intentional ritual that happens 1 or 2 time per day instead of obsessive doom scrolling you would do 24/7. Create environment where being semi-connected is encouraged, going online sporadically from time to time instead of being always connected.
I also don’t consider a mobile platform as feasible environment (except may be tablets? Especially with Linux?) and aim desktop-laptop kind of environments.
What is exist around?
The Briar is single project where there is some features combining longreads (via forums feature) and peer-to-peer connectivity with some “mailbox” (a server that would buffer messages to you while you are offline) which resembles a bit the online data pod I described above. But for now it is in maintenance mode.
The desire to provide local connectivity combined with instant messaging bumped into current limitation of existing tech, both in hardware and software scopes.
Question of the day
So the main question is following – is there any audience for software for local-first blogging with nomadic identity and online data pods like what I described above?
Error happened. -
An idea or concept for local-first blogging thingy
Reblog via Jeremiah Lee
The opposite of cloud computing is LEAF computing:
Local application logic and data
End-to-end encrypted data
Autonomous operation without non-optional dependencies
Federated capability between devices and connectivity with trusted partiesI seen this thanks to boost from Elena Rossini FOSDEM blog.
And this happened exactly when I thought about moving away from wordpress to something completely different. But this different thing, suddenly, does not exist at all yet. Or at least I do not know about its existence.
I will be as brief as possible. Imagine a blogging software with these traits:
Local-First
You have full copy of all your posts, media files, and even videos locally. Even the feed of authors you follow is fully local to most possible extent. You can read locally without internet, write replies and place reactions to them locally, even without the internet connection active.
Minimal network footprint
All what is necessary to keep it online is to connect sometimes, like 1-2 times per day or once per few days (but with larger packs of data to exchange) to a minimalistic online data pod.
This online data pod would consist of static pages generated from the posts, which would have some minimally interactive “islands” like comments section or reactions panel,
printbutton or some other pieces like images gallery or advanced image widget if used, with fallback to bare minimum thing if your reader disabled the JavaScript at all.The small backend purpose would be to accept incoming data via ActivityPub, WebMentions, SMTP, Git, or other possible means, and spread data to your followers with a job.
It would generate static pages from arriving your posts or regenerate them if related post have been updated.
From ActivityPub perspective the private messages would arrive to different inbox.
End-to-end encryption where applicable
Your data on this pod would be criptographically protected/signed but not encrypted by default (unless if this piece of data have been arrived in encrypted form to be encrypted by the sender (by you or some of your respondents).
Simple online storage at core
The core function of online data pod is to generate static pages from the arriving posts and media, serve it, spread updates to followers, and collect incoming reactions and replies.
Mostly it would consist of following parts:
- Static Files skin (layout, templates, styles, images)
- Generated pages and media (served as static but updated on changes)
- Signed data bucket (can be a simple set of files and directories but without direct public access, no database mandatory). You can set expiration age on any of your posts or messages.
- Arriving Data Cache (reactions, replies, data from followed authors). Can be implemented as another private directory. Cleared either as soon as downloaded to you or after reaching some age, such as 1 day or week.
- Jobs runner (spread updates to your followers, delete expired data).
- Data receptors (SMTP, IMAP, FTP, API requests handlers for ActivityPub and WebMentions, API handlers for interactive islands like comments and reactions section).
- Minimal metadata database built based on files from directores listed above where necessary and to keep state for jobs runner. Can be implemented as set of JSON files and special module with in-memory indexes and in-process API similar to how JSDB works. Used only where JSON files are not enough or be too slow/ineffective.
Most of these elements, you can notice, would work with 3-4 directories of files, like:
- long-term static. Public read-only access. never change after online data pod started
- Public generated static – public read-only access. can change while pod. Generated based on posts data and other events.
- Private protected data – private data that most of the time is readonly unless you edit it or delete from the editor and send the update.
- Arriving data – private data temporary stored until expire or until downloaded, or until processed by jobs runner, depending on what kind of data it is – your updates and new posts or it is
- Departing data – private data temporary stored until delivered or until become clear data delivery impossible and decision made to not delivery that data.
- Jobs runner states – private data used for scheduled jobs.
Connectivity hub and jobs runner
This is the place that goes beyond files storing. Ideally it would be something that can handle SFTP, IMAP, SMTP, and these HTTP API endpoints for ActivityPub and WebMentions necessary for federation part. This, to significant part, is why ever it can not be done via pure SFTP or IMAP or SMTP part.
Nomadic identity
I guess this is where it may be the most boring part of this, with all these digital signatures, authentication, and so on. Mostly it is about binding signing key to digital identity such as author or blog or organization or service. It is simply to say that:
- Use this public key to check whether
[email protected]nickname is author of posthttps://foo.bar.online/AliceCooks/Pancakes - Check with this (other?) key whether given direct message is from
[email protected] - Use this (third?) key to encrypt messages to the
[email protected]sent via SMTP (or ActivityPub?) - Public profile card details such as Alice The Space Cook title, profile pic, card background imagery, description, tags, topic spaces (labels from tree-like catalog like
alt.hobbbies.home.cookingand alike. - Previous key and signature (optional if this is not about changing the key)
- Digital signature of all this above with the first key from listed above.
- Endorsements – list of digital signatures with such cards from people who endorse (express their trust) to the claims above).
Note that all data is included into these cards, all images, descriptions, URLs, tags, and spaces is embedded. So card with endorsements can be quite big, up to 1 megabyte. But it is better than somehow store that at some centralized catalogue.
What really makes this identity nomadic is the fact you can multiple online pods or connectivity hubs storing your data or hop from one such hub to another together with your followers and contacts lists stored locally too.
Contacts and followers
The system of such cards described above would work even without classic DNS, but based on GnuNet GNS or local catalogue of “internet phone numbers” described by Aral Balkan in mentioned his post.
Daily Newspaper instead of endless feed
Instead of endless feed that causes intentional or unintentional doom scrolling, I would suggest to use locally-running code that would create using data downloaded from the online pod(s) a sort of “daily newspapers”, lets call it like “News for Breakfast”, “Evening Observer”, or “Climate Express” or “Solarpunk Tribune” or “Hightech news bulletin”. It is possible to create multiple various such newspapers working on your local data (what arrived during some timeframe) in various style. Some of these “newspapers” can include some global stuff, or use some global trending things, but this should be absolutely optional, and provided by following the related author which would provide such manually picked global news data or global topics or events and classification settings or both. Each of that would be separate offerings.
The whole such experience should be fully available locally, without connection to the internet, as soon as all related data downloaded.
Imagine if you open the app (at desktop or laptop!) and see two tables. One have Newspapers sign and looks exactly as the table with stack of newspapers. You pick one of them, and it opens in a way resembling the newspaper, with the front page content, and the rest content cut into pages. Of course the resemblance of newspaper is limited, and if you want, you can open the post(s) mentioned in the newspaper text or used to produce it.
The other table would look like a table with a pile of letters, you open in more or less letter-like experience, or that experience can be just a “boring email-like client” or something more like “messenger-like” experience or something between, but with letting people know it is NOT designed for chat-like instant messengers experience.
At a Glance
Together this may look as something not very powerful, as many people today assume that any software aiming to be “successful” or “widespread” should have audio-video calls and instant messaging features.
Capabilities
The software I describing is mostly centered around these capabilities intentionally:
- public long read posts with formatting and attached media and cached embeds for links.
- Public reactions, comments and reposts
- Private messages with e2ee capabilities
- Contacts card collection, exchange and endorsement
- Daily newspaper-like thing instead of “feed-like” experience
Big parts
These 2 completely different parts are necessary:
- Local-first desktop software (blog editor based on Markdown full support (including sanitized html blocks and CSS for advanced formatting), messages a-la mix of email and asynchronous chat, and contacts cards library)
- Online data pod that would work as public data point and node for the system. Multiple pods can be used by same person. It should use as basic and widespread protocols as possible, such as SFTP, SMTP, and IMAP, and open standards as ActivityPub, WebMentions, WebIntents.
Moderation and abuse reporting not covered, but doable
This idea does not cover such aspects as moderation, abuse reporting, or preventing local abuse.
Regarding local abuse like relatives opening your PC without your pemission. It is terrible thing even to mention, while I personally I did not experience anything like that. I just remember some blog post describing these treats and related problems. Software for these kinds of treats model surely completely different and needs another set of capabilities like “delete all password”, “fake/safe data” credentials, and even local data should be encrypted similar to how Aegis 2FA OTP manager or some SimpleXChat messenger clients stores their database and require to type password to open the database.
Regarding moderation abuse reporting, situation is more complicated. To significant extent, the moderation can be done locally with various tools such as blocklists/mute lists, and regarding abuse reporting, it mostly about contact de-endorsement via some high-trusted third-party, who has been chosen by person who report abuse as moderator.
As the online data pods can be run by anyone, and not necessary it would be some mass service for such pods, it can be complicated to really “block” someone. De-endorsement would have strong effect, if moderator chosen by many or trusted by many (like “I may not use moderation services by Foo Bar, but I will accept de-endorsements” they may issue.
De-endorsements are public and special kind of posts.
Endorsements can be private in sense that such endorsement issued about one contact A for another B by a contact C and only C and C know about that. Or they can be public, with special kind of post.
Endorsement and de-endorsement posts are consists of contact cards being endorsed and de-endorsed.
Blocklists can be about contact cards (specific digital identity), or about online data pods (same as domain block or de-federate in Mastodon), spaces or tags or mix of these above. Technically blocklists are public blogs following special formatting.
Moderation labels can be applied to the contacts and posts by moderators which are more like labeling, and it not necessary means muting or blocking or de-endorsement, but for some of moderation labels it can mean de-endorsement. For example if you are a moderator and place moderation label
disinformationon post or account, this is not same as placing tagdisinformationon blog post debunking some disinformation or exposing another propaganda network.Still, due local-first nature of the project, the actual moderation can happen only locally, except for case when you follow some blocklist or do not want to see content labeled as
sex and pornorviolenceby moderators or even having tag (not moderation label but tag)nsfwyou can update your online data pod to silently ignore such data on arrival, so it even would not be saved at pod, and will not be arrived into local data as well.Following a moderation posts blog and expressing related level of trust (“I will use this blocklist and that labeling service”) at local settings and online data pod configuration is single way to implement moderation for local-first project.
Questions and Examples on Newspaper format
Is there a way to make such “newspapers generator” without LLMs? Are there more specialized algorithms for tasks like that? To take various posts sequence for some time interval, or multiple such sequences, mix with global events definition list, and produce newspaper-like format, consisting of some pages of text and images, sorted by priority, to be sure the most important go to first few screens? Or without sorting but just with grouping?
I would like to avoid LLMs, even locally running, for feature like that.
For global news, such newspaper can be human made like how the Civil.ge newsletter Morning Cable works.
But what is alternative to LLMs if make this kind of “newspaper” in more or less automated way? Like…
Today SuperSun writes about upcycling practices in solarpunk community Optimistic Valley and describes how abandoned warehouse become a creative recreational and living space for the community and what the struggle it was to get all necessary permits from local council.
19 people commented this and expressed 128 reactions. The most surprising was disbelief expressed by CringyPunk what caused notable responses both from SuperSun (author) and BringingSunHere
Or another type of thing what can land in the “Newspaper” regarding global news:
The latest Russian strikes against Ukrainian civilians caused widespread condemnation and widespread criticism from your contacts. Some authors you follow try to use satire and humor to cope with the horror of war and another wave of destruction and death. It works partly because such strikes does not help Russian genocidal empire to reach their military objectives, ISW notes. Quite opposite. Also, more EU and US sanctions to come in response.
And third example for such newspaper blocks:
The ongoing football world cup event sparked lot of emotions from your contacts. 10 of people you follow expressed joy on catastrophic loss of US team to Belgium with 4-1 scores while BoringSceptic wrote a grumpy longread on how the big sport funnels private and public money away from top priorities and used solely for propaganda by the dictatorships for decades.
These are random examples of how these blocks in newspaper-like stuff would like.
Online Pod services
Even with all these tutorials floating around about self-hosting and blog about Elena Rossini Sudo Life covering her fascinating self-hosting adventures, not everyone have time to self-host, and if we would like to land more people to platform like what I described, it would require some online data pod service, like hosting service running analog of Domain software for kitten by Aral Balkan.
It is likely that some of such services could be a paid ones, others would try to cover up expenses with donations via Patreon and other ways.
Other such services can use one-time entry payment instead of regular payments just to protect self from spam and disinfo bots.
Limitations
The project is not about total anonymity or full-blown censorship resistance.
Some of well-trusted endorcers may use video call where you would speak with them and show your id card or something like that to check you are surely not a bot or ensure that you are really who you claim to be. But not every endorsement would come from such service.
The project does not require to use some advanced protocols or tech like Tor for anonymization or I2P or other peer-to-peer connectivity for directly connecting with your authors.
The whole idea of online data pods is a way to overcome the fact that internet is a set of pyramids, such as SSL certificates tree, DNS system is based on centralized names tree prune to censorship and attacks, that is why it is pure optional for this system to work. And the whole IP addresses space is non-uniform – so called residential IP addresses are restricted or second-class citizens, as it often happens with SMTP due spam flood happening with email.
The project intentionally avoid use cases which require instant messaging capabilities or real-time connectivity like audio-video calls. The whole idea of this project is to create environment encouraging you to making reading of news some intentional ritual that happens 1 or 2 time per day instead of obsessive doom scrolling you would do 24/7. Create environment where being semi-connected is encouraged, going online sporadically from time to time instead of being always connected.
I also don’t consider a mobile platform as feasible environment (except may be tablets? Especially with Linux?) and aim desktop-laptop kind of environments.
What is exist around?
The Briar is single project where there is some features combining longreads (via forums feature) and peer-to-peer connectivity with some “mailbox” (a server that would buffer messages to you while you are offline) which resembles a bit the online data pod I described above. But for now it is in maintenance mode.
The desire to provide local connectivity combined with instant messaging bumped into current limitation of existing tech, both in hardware and software scopes.
Question of the day
So the main question is following – is there any audience for software for local-first blogging with nomadic identity and online data pods like what I described above?
-
One caveat I might have, and this is not an issue with the article, of course, and I generally agree that "the fediverse needs more apps", but!
This is where the Atmosphere has a big advantage.
Yes, some of us might prefer to have separate accounts on different servers and platforms, and keep individual hobbies, interests, and other layers of our personality separate. I think that's fine.
But some of us might prefer to manage one account, and until nomadic identity is widely supported across the fediverse, having more apps to sign up for might not entice everyone.
Just a thought!
https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse
-
One caveat I might have, and this is not an issue with the article, of course, and I generally agree that "the fediverse needs more apps", but!
This is where the Atmosphere has a big advantage.
Yes, some of us might prefer to have separate accounts on different servers and platforms, and keep individual hobbies, interests, and other layers of our personality separate. I think that's fine.
But some of us might prefer to manage one account, and until nomadic identity is widely supported across the fediverse, having more apps to sign up for might not entice everyone.
Just a thought!
https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse
-
One caveat I might have, and this is not an issue with the article, of course, and I generally agree that "the fediverse needs more apps", but!
This is where the Atmosphere has a big advantage.
Yes, some of us might prefer to have separate accounts on different servers and platforms, and keep individual hobbies, interests, and other layers of our personality separate. I think that's fine.
But some of us might prefer to manage one account, and until nomadic identity is widely supported across the fediverse, having more apps to sign up for might not entice everyone.
Just a thought!
https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse
-
One caveat I might have, and this is not an issue with the article, of course, and I generally agree that "the fediverse needs more apps", but!
This is where the Atmosphere has a big advantage.
Yes, some of us might prefer to have separate accounts on different servers and platforms, and keep individual hobbies, interests, and other layers of our personality separate. I think that's fine.
But some of us might prefer to manage one account, and until nomadic identity is widely supported across the fediverse, having more apps to sign up for might not entice everyone.
Just a thought!
https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse
-
One caveat I might have, and this is not an issue with the article, of course, and I generally agree that "the fediverse needs more apps", but!
This is where the Atmosphere has a big advantage.
Yes, some of us might prefer to have separate accounts on different servers and platforms, and keep individual hobbies, interests, and other layers of our personality separate. I think that's fine.
But some of us might prefer to manage one account, and until nomadic identity is widely supported across the fediverse, having more apps to sign up for might not entice everyone.
Just a thought!
https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse
-
FEP-ef61: Portable Objects has been updated: https://codeberg.org/fediverse/fep/pulls/872
The
ap+ef61URI scheme is now allowed, whileapremains the recommended one. This is to ensure compatibility with @fedify whose maintainers decided to use theap+ef61scheme until the specification is finalized. -
FEP-ef61: Portable Objects has been updated: https://codeberg.org/fediverse/fep/pulls/872
The
ap+ef61URI scheme is now allowed, whileapremains the recommended one. This is to ensure compatibility with @fedify whose maintainers decided to use theap+ef61scheme until the specification is finalized. -
FEP-ef61: Portable Objects has been updated: https://codeberg.org/fediverse/fep/pulls/872
The
ap+ef61URI scheme is now allowed, whileapremains the recommended one. This is to ensure compatibility with @fedify whose maintainers decided to use theap+ef61scheme until the specification is finalized. -
FEP-ef61: Portable Objects has been updated: https://codeberg.org/fediverse/fep/pulls/872
The
ap+ef61URI scheme is now allowed, whileapremains the recommended one. This is to ensure compatibility with @fedify whose maintainers decided to use theap+ef61scheme until the specification is finalized. -
@InnocentZero FEP-ef61 all by itself isn't a magical solution. It's just one element in implementing full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) via ActivityPub, but it's far from being the only one.
See, nomadic identity wasn't invented just a few years ago or so, and it wasn't invented for, on and with ActivityPub either. It was first introduced in Fediverse software that works vastly, vastly different from Mastodon and from most of the rest of the Fediverse. I'm daily-driving what became of this software.The beginning of nomadic identity: the Zot protocol, Red and Hubzilla
Nomadic identity was invented in 2011 by @Mike Macgirvin who had made Friendica (https://friendi.ca, https://en.wikipedia.org/wiki/Friendica, https://joinfediverse.wiki/Friendica) as early as 2010. (Friendica is the oldest still existing Fediverse software, by the way.)
To put this into perspective: The concept of nomadic identity is over four years older than Mastodon. And it predates the first ActivityPub implementation by some six years. (Ironically, the software that first implemented ActivityPub is essentially the same software that first implemented nomadic identity.)
One issue that plagued Friendica is an issue that plagues everything decentralised: Servers shut down out of the blue, and users lose everything. That's why Mike had the idea to make identities not only portable (as in, easy to move from one server to another), but nomadic (as in, absolutely identical clones of the same identity exist on multiple independent servers at the same time, so if one server shuts down, you lose nothing).
Still in 2011, Mike designed a wholly new federated protocol named Zot to implement nomadic identity. Mind you, he had already designed a brand-new protocol from scratch for Friendica.
In 2012, Mike took his own Red, a development-grade fork of his own official development fork of Friendica. He pretty much ripped the whole backend out and also most of the frontend, and he basically developed an entirely new server application, now built against Zot. This was necessary because Red would have to handle identities completely differently from Friendica in order to make them nomadic.
See, Friendica handles identities just like Mastodon and almost the entire rest of the Fediverse: Your identity is your account, your login. You have one identity per login, you have one identity per server. All your data, all your stuff is stored directly in your account.
But you can't clone accounts. It's way too tedious to separate the stuff that must be cloned (contacts, messages, settings etc.) from the stuff that mustn't be cloned (login credentials).
So Mike created the concept of "channels" (https://joinfediverse.wiki/Channels_(Hubzilla_%26_(streams))). They're basically containers for your identity that contain everything except the login credentials on the servers. They can easily be cloned and moved as a whole.
Red still exists in a way: Later the same year, it was renamed the Red Matrix. And in 2015, it was completely refactored, it was greatly expanded in features and functionality, and it was renamed Hubzilla (https://hubzilla.org, https://en.wikipedia.org/wiki/Hubzilla, https://joinfediverse.wiki/Hubzilla). Hubzilla is where I'm commenting from right now, and this channel has been cloned for longer than most Mastodon users have known that Mastodon exists.Nomadic identity via only ActivityPub: (streams), Mitra and forte
FEP-ef61 was created by @silverpill, developer of Mitra (https://codeberg.org/silverpill/mitra) in 2023. The goal was to take non-nomadic, account-equals-identity Mitra and make it every bit as nomadic as Hubzilla. Not by rewriting the entire backend against Zot (or its newest version known as Nomad) and then bolting ActivityPub support back on, but by using nothing but ActivityPub itself without rewriting the backend.
Development and sparrings partner became Mike Macgirvin himself who, at that time, was working on the streams repository (https://joinfediverse.wiki/(streams), https://codeberg.org/streams/streams), a Nomad-based fork of a fork of three forks of a fork (of a fork) of Hubzilla, somewhat slimmed down in features (it isn't a full-blown, jack-of-all-trades CMS unlike Hubzilla), but every bit as nomadic as Hubzilla.
The two worked out a way of using ActivityPub and only ActivityPub to establish nomadic identity. Not only to made Fediverse identifiers independent from servers, but to actually use ActivityPub to clone identities with everything attached to them between servers.
Eventually, FEP-ef61 was defined, and (streams) and Mitra became the first Fediverse server applications to understand portable identities as per FEP-ef61. (streams) was the first nomadic Fediverse server application to understand them, but it still uses its native Nomad protocol for its own nomadicity. Mitra, all by itself, still isn't nomadic to this day; it uses a client named Minimitra for nomadicity.
The first Fediverse server application that actually uses only ActivityPub for nomadicity, all the way to cloning and syncing channels, is Forte (https://codeberg.org/fortified/forte). It came to exist in mid-August 2024, essentially as a byproduct of an accident. (streams) had to juggle so many identities already, ActivityPub identities, Nomad identities, Zot6 identities, that when FEP-ef61 was merged into its release branch, it confused all these identities and didn't connect or federate with anything anymore. In order to find and fix the issue, Mike Macgirvin himself forked his own streams repository and ripped out any and all support for protocols that weren't ActivityPub. This required Forte to use ActivityPub for everything that (streams) used Nomad for.Where we are now
So as of now, there are exactly three still existing server applications with full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity: Zot-based Hubzilla from 2012/2015, Nomad-based (streams) from 2021 and ActivityPub-based Forte from 2024.
There is only one of this kind that uses ActivityPub for everything, including nomadicity, and that's Forte.
Forte is the youngest member of the same software family as Hubzilla and (streams). They were all created by the same developer, and they were all born nomadic.
There is no case of a typical, classic, non-nomadic, account-equals-identity, ActivityPub-based Fediverse server application that was successfully converted to full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity. Forte itself wasn't converted from non-nomadic to nomadic; it was converted from Nomad-based to ActivityPub-based while having a nomadic legacy that dated back a dozen years at that point.
I'm not saying that it's impossible to turn non-nomadic software into fully nomadic software. But it's a huge undertaking that will require rewriting large parts of the server backend.
Essentially: You can't just add FEP-ef61 support to Mastodon and immediately clone your account over to other servers the same way that I can clone my Hubzilla channel.
CC: @Rob Ricci @Christine Lemmer-Webber
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Red #RedMatrix #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity -
@InnocentZero FEP-ef61 all by itself isn't a magical solution. It's just one element in implementing full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) via ActivityPub, but it's far from being the only one.
See, nomadic identity wasn't invented just a few years ago or so, and it wasn't invented for, on and with ActivityPub either. It was first introduced in Fediverse software that works vastly, vastly different from Mastodon and from most of the rest of the Fediverse. I'm daily-driving what became of this software.The beginning of nomadic identity: the Zot protocol, Red and Hubzilla
Nomadic identity was invented in 2011 by @Mike Macgirvin who had made Friendica (https://friendi.ca, https://en.wikipedia.org/wiki/Friendica, https://joinfediverse.wiki/Friendica) as early as 2010. (Friendica is the oldest still existing Fediverse software, by the way.)
To put this into perspective: The concept of nomadic identity is over four years older than Mastodon. And it predates the first ActivityPub implementation by some six years. (Ironically, the software that first implemented ActivityPub is essentially the same software that first implemented nomadic identity.)
One issue that plagued Friendica is an issue that plagues everything decentralised: Servers shut down out of the blue, and users lose everything. That's why Mike had the idea to make identities not only portable (as in, easy to move from one server to another), but nomadic (as in, absolutely identical clones of the same identity exist on multiple independent servers at the same time, so if one server shuts down, you lose nothing).
Still in 2011, Mike designed a wholly new federated protocol named Zot to implement nomadic identity. Mind you, he had already designed a brand-new protocol from scratch for Friendica.
In 2012, Mike took his own Red, a development-grade fork of his own official development fork of Friendica. He pretty much ripped the whole backend out and also most of the frontend, and he basically developed an entirely new server application, now built against Zot. This was necessary because Red would have to handle identities completely differently from Friendica in order to make them nomadic.
See, Friendica handles identities just like Mastodon and almost the entire rest of the Fediverse: Your identity is your account, your login. You have one identity per login, you have one identity per server. All your data, all your stuff is stored directly in your account.
But you can't clone accounts. It's way too tedious to separate the stuff that must be cloned (contacts, messages, settings etc.) from the stuff that mustn't be cloned (login credentials).
So Mike created the concept of "channels" (https://joinfediverse.wiki/Channels_(Hubzilla_%26_(streams))). They're basically containers for your identity that contain everything except the login credentials on the servers. They can easily be cloned and moved as a whole.
Red still exists in a way: Later the same year, it was renamed the Red Matrix. And in 2015, it was completely refactored, it was greatly expanded in features and functionality, and it was renamed Hubzilla (https://hubzilla.org, https://en.wikipedia.org/wiki/Hubzilla, https://joinfediverse.wiki/Hubzilla). Hubzilla is where I'm commenting from right now, and this channel has been cloned for longer than most Mastodon users have known that Mastodon exists.Nomadic identity via only ActivityPub: (streams), Mitra and forte
FEP-ef61 was created by @silverpill, developer of Mitra (https://codeberg.org/silverpill/mitra) in 2023. The goal was to take non-nomadic, account-equals-identity Mitra and make it every bit as nomadic as Hubzilla. Not by rewriting the entire backend against Zot (or its newest version known as Nomad) and then bolting ActivityPub support back on, but by using nothing but ActivityPub itself without rewriting the backend.
Development and sparrings partner became Mike Macgirvin himself who, at that time, was working on the streams repository (https://joinfediverse.wiki/(streams), https://codeberg.org/streams/streams), a Nomad-based fork of a fork of three forks of a fork (of a fork) of Hubzilla, somewhat slimmed down in features (it isn't a full-blown, jack-of-all-trades CMS unlike Hubzilla), but every bit as nomadic as Hubzilla.
The two worked out a way of using ActivityPub and only ActivityPub to establish nomadic identity. Not only to made Fediverse identifiers independent from servers, but to actually use ActivityPub to clone identities with everything attached to them between servers.
Eventually, FEP-ef61 was defined, and (streams) and Mitra became the first Fediverse server applications to understand portable identities as per FEP-ef61. (streams) was the first nomadic Fediverse server application to understand them, but it still uses its native Nomad protocol for its own nomadicity. Mitra, all by itself, still isn't nomadic to this day; it uses a client named Minimitra for nomadicity.
The first Fediverse server application that actually uses only ActivityPub for nomadicity, all the way to cloning and syncing channels, is Forte (https://codeberg.org/fortified/forte). It came to exist in mid-August 2024, essentially as a byproduct of an accident. (streams) had to juggle so many identities already, ActivityPub identities, Nomad identities, Zot6 identities, that when FEP-ef61 was merged into its release branch, it confused all these identities and didn't connect or federate with anything anymore. In order to find and fix the issue, Mike Macgirvin himself forked his own streams repository and ripped out any and all support for protocols that weren't ActivityPub. This required Forte to use ActivityPub for everything that (streams) used Nomad for.Where we are now
So as of now, there are exactly three still existing server applications with full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity: Zot-based Hubzilla from 2012/2015, Nomad-based (streams) from 2021 and ActivityPub-based Forte from 2024.
There is only one of this kind that uses ActivityPub for everything, including nomadicity, and that's Forte.
Forte is the youngest member of the same software family as Hubzilla and (streams). They were all created by the same developer, and they were all born nomadic.
There is no case of a typical, classic, non-nomadic, account-equals-identity, ActivityPub-based Fediverse server application that was successfully converted to full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity. Forte itself wasn't converted from non-nomadic to nomadic; it was converted from Nomad-based to ActivityPub-based while having a nomadic legacy that dated back a dozen years at that point.
I'm not saying that it's impossible to turn non-nomadic software into fully nomadic software. But it's a huge undertaking that will require rewriting large parts of the server backend.
Essentially: You can't just add FEP-ef61 support to Mastodon and immediately clone your account over to other servers the same way that I can clone my Hubzilla channel.
CC: @Rob Ricci @Christine Lemmer-Webber
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Red #RedMatrix #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity -
@InnocentZero FEP-ef61 all by itself isn't a magical solution. It's just one element in implementing full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) via ActivityPub, but it's far from being the only one.
See, nomadic identity wasn't invented just a few years ago or so, and it wasn't invented for, on and with ActivityPub either. It was first introduced in Fediverse software that works vastly, vastly different from Mastodon and from most of the rest of the Fediverse. I'm daily-driving what became of this software.The beginning of nomadic identity: the Zot protocol, Red and Hubzilla
Nomadic identity was invented in 2011 by @Mike Macgirvin who had made Friendica (https://friendi.ca, https://en.wikipedia.org/wiki/Friendica, https://joinfediverse.wiki/Friendica) as early as 2010. (Friendica is the oldest still existing Fediverse software, by the way.)
To put this into perspective: The concept of nomadic identity is over four years older than Mastodon. And it predates the first ActivityPub implementation by some six years. (Ironically, the software that first implemented ActivityPub is essentially the same software that first implemented nomadic identity.)
One issue that plagued Friendica is an issue that plagues everything decentralised: Servers shut down out of the blue, and users lose everything. That's why Mike had the idea to make identities not only portable (as in, easy to move from one server to another), but nomadic (as in, absolutely identical clones of the same identity exist on multiple independent servers at the same time, so if one server shuts down, you lose nothing).
Still in 2011, Mike designed a wholly new federated protocol named Zot to implement nomadic identity. Mind you, he had already designed a brand-new protocol from scratch for Friendica.
In 2012, Mike took his own Red, a development-grade fork of his own official development fork of Friendica. He pretty much ripped the whole backend out and also most of the frontend, and he basically developed an entirely new server application, now built against Zot. This was necessary because Red would have to handle identities completely differently from Friendica in order to make them nomadic.
See, Friendica handles identities just like Mastodon and almost the entire rest of the Fediverse: Your identity is your account, your login. You have one identity per login, you have one identity per server. All your data, all your stuff is stored directly in your account.
But you can't clone accounts. It's way too tedious to separate the stuff that must be cloned (contacts, messages, settings etc.) from the stuff that mustn't be cloned (login credentials).
So Mike created the concept of "channels" (https://joinfediverse.wiki/Channels_(Hubzilla_%26_(streams))). They're basically containers for your identity that contain everything except the login credentials on the servers. They can easily be cloned and moved as a whole.
Red still exists in a way: Later the same year, it was renamed the Red Matrix. And in 2015, it was completely refactored, it was greatly expanded in features and functionality, and it was renamed Hubzilla (https://hubzilla.org, https://en.wikipedia.org/wiki/Hubzilla, https://joinfediverse.wiki/Hubzilla). Hubzilla is where I'm commenting from right now, and this channel has been cloned for longer than most Mastodon users have known that Mastodon exists.Nomadic identity via only ActivityPub: (streams), Mitra and forte
FEP-ef61 was created by @silverpill, developer of Mitra (https://codeberg.org/silverpill/mitra) in 2023. The goal was to take non-nomadic, account-equals-identity Mitra and make it every bit as nomadic as Hubzilla. Not by rewriting the entire backend against Zot (or its newest version known as Nomad) and then bolting ActivityPub support back on, but by using nothing but ActivityPub itself without rewriting the backend.
Development and sparrings partner became Mike Macgirvin himself who, at that time, was working on the streams repository (https://joinfediverse.wiki/(streams), https://codeberg.org/streams/streams), a Nomad-based fork of a fork of three forks of a fork (of a fork) of Hubzilla, somewhat slimmed down in features (it isn't a full-blown, jack-of-all-trades CMS unlike Hubzilla), but every bit as nomadic as Hubzilla.
The two worked out a way of using ActivityPub and only ActivityPub to establish nomadic identity. Not only to made Fediverse identifiers independent from servers, but to actually use ActivityPub to clone identities with everything attached to them between servers.
Eventually, FEP-ef61 was defined, and (streams) and Mitra became the first Fediverse server applications to understand portable identities as per FEP-ef61. (streams) was the first nomadic Fediverse server application to understand them, but it still uses its native Nomad protocol for its own nomadicity. Mitra, all by itself, still isn't nomadic to this day; it uses a client named Minimitra for nomadicity.
The first Fediverse server application that actually uses only ActivityPub for nomadicity, all the way to cloning and syncing channels, is Forte (https://codeberg.org/fortified/forte). It came to exist in mid-August 2024, essentially as a byproduct of an accident. (streams) had to juggle so many identities already, ActivityPub identities, Nomad identities, Zot6 identities, that when FEP-ef61 was merged into its release branch, it confused all these identities and didn't connect or federate with anything anymore. In order to find and fix the issue, Mike Macgirvin himself forked his own streams repository and ripped out any and all support for protocols that weren't ActivityPub. This required Forte to use ActivityPub for everything that (streams) used Nomad for.Where we are now
So as of now, there are exactly three still existing server applications with full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity: Zot-based Hubzilla from 2012/2015, Nomad-based (streams) from 2021 and ActivityPub-based Forte from 2024.
There is only one of this kind that uses ActivityPub for everything, including nomadicity, and that's Forte.
Forte is the youngest member of the same software family as Hubzilla and (streams). They were all created by the same developer, and they were all born nomadic.
There is no case of a typical, classic, non-nomadic, account-equals-identity, ActivityPub-based Fediverse server application that was successfully converted to full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity. Forte itself wasn't converted from non-nomadic to nomadic; it was converted from Nomad-based to ActivityPub-based while having a nomadic legacy that dated back a dozen years at that point.
I'm not saying that it's impossible to turn non-nomadic software into fully nomadic software. But it's a huge undertaking that will require rewriting large parts of the server backend.
Essentially: You can't just add FEP-ef61 support to Mastodon and immediately clone your account over to other servers the same way that I can clone my Hubzilla channel.
CC: @Rob Ricci @Christine Lemmer-Webber
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Red #RedMatrix #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity -
https://joinfediverse.wiki/Nomadic_identity
Nomadic identity is a feature currently available only to Hubzilla and its latest successor commonly referred to as (streams). It provides a unique way of moving between instances fairly easily and even cloning your Fediverse identity. It is not available for or compatible with ActivityPub, though.
This page needs an update.
-
https://joinfediverse.wiki/Nomadic_identity
Nomadic identity is a feature currently available only to Hubzilla and its latest successor commonly referred to as (streams). It provides a unique way of moving between instances fairly easily and even cloning your Fediverse identity. It is not available for or compatible with ActivityPub, though.
This page needs an update.
-
https://joinfediverse.wiki/Nomadic_identity
Nomadic identity is a feature currently available only to Hubzilla and its latest successor commonly referred to as (streams). It provides a unique way of moving between instances fairly easily and even cloning your Fediverse identity. It is not available for or compatible with ActivityPub, though.
This page needs an update.
-
https://joinfediverse.wiki/Nomadic_identity
Nomadic identity is a feature currently available only to Hubzilla and its latest successor commonly referred to as (streams). It provides a unique way of moving between instances fairly easily and even cloning your Fediverse identity. It is not available for or compatible with ActivityPub, though.
This page needs an update.
-
@ValorZard No dice.
First of all, implementing nomadic identity would drastically alter the way how Mastodon works. It would make Mastodon, something that's supposed to be dead-simple, a great deal more complex.
I mean, in order to really pull this through all the way (as in Hubzilla/(streams)/Forte-level nomadic identity), your identity, your posts, your followers, your followed, your settings, your filters, your everything, all this must no longer directly reside in your account. It must be containerised in something that Hubzilla calls "channel", and that container would then reside in your account and be able to reside in multiple accounts on multiple independent servers.
Next, when Mastodon introduces a new feature, they tend to try to market it as their own original pioneering invention. They can't do that with nomadic identity. There are already enough people who know that nomadic identity was actually pioneered by Hubzilla before Mastodon even existed.
Furthermore, before Gargron implements something invented by Mike Macgirvin, hell will freeze over. Even if he tried to sell it as a unique feature of Mastodon, he'd still secretly have to admit that there's something that Mike did right. And quite a few eyes would be on him in hope of Mastodon getting more features from stuff created by Mike.
Ever heard of OpenWebAuth magic sign-on? Invented by Mike for Osada and Zap in the late 2010s, then backported to Hubzilla.
It was proposed for Mastodon, even if it was only client-side (as in, Mastodon logins would be detected by Hubzilla, (streams) and Forte, but Mastodon wouldn't be able to detect OpenWebAuth logins itself). This went as far as a merge request on GitHub. It could have been built into Mastodon. The code was literally there.
The merge request was silently rejected. And that would have been a fairly small change in comparison to the complete rebuild that'd be necessary for a full-blown, Forte-level, server-side implementation of nomadic identity.
I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon, what with every other Fediverse app being a Mastodon client. Mastodon would require a server-side implementation.
Seriously, it'd be easier to strap Mastodon's Web UI to Forte or Hubzilla with the necessary changes to adapt it to a vastly different backend.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity -
@ValorZard No dice.
First of all, implementing nomadic identity would drastically alter the way how Mastodon works. It would make Mastodon, something that's supposed to be dead-simple, a great deal more complex.
I mean, in order to really pull this through all the way (as in Hubzilla/(streams)/Forte-level nomadic identity), your identity, your posts, your followers, your followed, your settings, your filters, your everything, all this must no longer directly reside in your account. It must be containerised in something that Hubzilla calls "channel", and that container would then reside in your account and be able to reside in multiple accounts on multiple independent servers.
Next, when Mastodon introduces a new feature, they tend to try to market it as their own original pioneering invention. They can't do that with nomadic identity. There are already enough people who know that nomadic identity was actually pioneered by Hubzilla before Mastodon even existed.
Furthermore, before Gargron implements something invented by Mike Macgirvin, hell will freeze over. Even if he tried to sell it as a unique feature of Mastodon, he'd still secretly have to admit that there's something that Mike did right. And quite a few eyes would be on him in hope of Mastodon getting more features from stuff created by Mike.
Ever heard of OpenWebAuth magic sign-on? Invented by Mike for Osada and Zap in the late 2010s, then backported to Hubzilla.
It was proposed for Mastodon, even if it was only client-side (as in, Mastodon logins would be detected by Hubzilla, (streams) and Forte, but Mastodon wouldn't be able to detect OpenWebAuth logins itself). This went as far as a merge request on GitHub. It could have been built into Mastodon. The code was literally there.
The merge request was silently rejected. And that would have been a fairly small change in comparison to the complete rebuild that'd be necessary for a full-blown, Forte-level, server-side implementation of nomadic identity.
I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon, what with every other Fediverse app being a Mastodon client. Mastodon would require a server-side implementation.
Seriously, it'd be easier to strap Mastodon's Web UI to Forte or Hubzilla with the necessary changes to adapt it to a vastly different backend.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity -
@ValorZard No dice.
First of all, implementing nomadic identity would drastically alter the way how Mastodon works. It would make Mastodon, something that's supposed to be dead-simple, a great deal more complex.
I mean, in order to really pull this through all the way (as in Hubzilla/(streams)/Forte-level nomadic identity), your identity, your posts, your followers, your followed, your settings, your filters, your everything, all this must no longer directly reside in your account. It must be containerised in something that Hubzilla calls "channel", and that container would then reside in your account and be able to reside in multiple accounts on multiple independent servers.
Next, when Mastodon introduces a new feature, they tend to try to market it as their own original pioneering invention. They can't do that with nomadic identity. There are already enough people who know that nomadic identity was actually pioneered by Hubzilla before Mastodon even existed.
Furthermore, before Gargron implements something invented by Mike Macgirvin, hell will freeze over. Even if he tried to sell it as a unique feature of Mastodon, he'd still secretly have to admit that there's something that Mike did right. And quite a few eyes would be on him in hope of Mastodon getting more features from stuff created by Mike.
Ever heard of OpenWebAuth magic sign-on? Invented by Mike for Osada and Zap in the late 2010s, then backported to Hubzilla.
It was proposed for Mastodon, even if it was only client-side (as in, Mastodon logins would be detected by Hubzilla, (streams) and Forte, but Mastodon wouldn't be able to detect OpenWebAuth logins itself). This went as far as a merge request on GitHub. It could have been built into Mastodon. The code was literally there.
The merge request was silently rejected. And that would have been a fairly small change in comparison to the complete rebuild that'd be necessary for a full-blown, Forte-level, server-side implementation of nomadic identity.
I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon, what with every other Fediverse app being a Mastodon client. Mastodon would require a server-side implementation.
Seriously, it'd be easier to strap Mastodon's Web UI to Forte or Hubzilla with the necessary changes to adapt it to a vastly different backend.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity -
@ValorZard No dice.
First of all, implementing nomadic identity would drastically alter the way how Mastodon works. It would make Mastodon, something that's supposed to be dead-simple, a great deal more complex.
I mean, in order to really pull this through all the way (as in Hubzilla/(streams)/Forte-level nomadic identity), your identity, your posts, your followers, your followed, your settings, your filters, your everything, all this must no longer directly reside in your account. It must be containerised in something that Hubzilla calls "channel", and that container would then reside in your account and be able to reside in multiple accounts on multiple independent servers.
Next, when Mastodon introduces a new feature, they tend to try to market it as their own original pioneering invention. They can't do that with nomadic identity. There are already enough people who know that nomadic identity was actually pioneered by Hubzilla before Mastodon even existed.
Furthermore, before Gargron implements something invented by Mike Macgirvin, hell will freeze over. Even if he tried to sell it as a unique feature of Mastodon, he'd still secretly have to admit that there's something that Mike did right. And quite a few eyes would be on him in hope of Mastodon getting more features from stuff created by Mike.
Ever heard of OpenWebAuth magic sign-on? Invented by Mike for Osada and Zap in the late 2010s, then backported to Hubzilla.
It was proposed for Mastodon, even if it was only client-side (as in, Mastodon logins would be detected by Hubzilla, (streams) and Forte, but Mastodon wouldn't be able to detect OpenWebAuth logins itself). This went as far as a merge request on GitHub. It could have been built into Mastodon. The code was literally there.
The merge request was silently rejected. And that would have been a fairly small change in comparison to the complete rebuild that'd be necessary for a full-blown, Forte-level, server-side implementation of nomadic identity.
I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon, what with every other Fediverse app being a Mastodon client. Mastodon would require a server-side implementation.
Seriously, it'd be easier to strap Mastodon's Web UI to Forte or Hubzilla with the necessary changes to adapt it to a vastly different backend.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity -
@silverpill Would be interesting to add Hubzilla's Zot6 and (streams)' Nomad (which would be Zot12 if it wasn't incompatible with Zot6) to the list.
By the way: Forte doesn't require a gateway to communicate with non-nomadic ActivityPub. A fully cloned Forte channel can communicate with a Mastodon account without jumping through hoops. Remember that Forte has almost fully-featured Hubzilla-level nomadic identity (i.e. everything except real-time syncing between channel instances; unlike Hubzilla and (streams) which do sync in real time, it needs a cronjob for that) directly built into its core.
(streams) does support nomadic identity via ActivityPub. But internally, it uses and relies upon Nomad for its nomadic identity. It only supports nomadic identity via ActivityPub a) because it was used as a development platform for just this and b) in order to be able to understand cloned nomadic ActivityPub actors elsewhere. This is also why it isn't possible to move from (streams) to Forte, to move from Forte to (streams) or to clone between (streams) and Forte.
(streams) itself doesn't require gateways to communicate with Mastodon & Co. either. It speaks three protocols natively: its own Nomad, Hubzilla's Zot6 and (optionally, but on by default) standard ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@silverpill Would be interesting to add Hubzilla's Zot6 and (streams)' Nomad (which would be Zot12 if it wasn't incompatible with Zot6) to the list.
By the way: Forte doesn't require a gateway to communicate with non-nomadic ActivityPub. A fully cloned Forte channel can communicate with a Mastodon account without jumping through hoops. Remember that Forte has almost fully-featured Hubzilla-level nomadic identity (i.e. everything except real-time syncing between channel instances; unlike Hubzilla and (streams) which do sync in real time, it needs a cronjob for that) directly built into its core.
(streams) does support nomadic identity via ActivityPub. But internally, it uses and relies upon Nomad for its nomadic identity. It only supports nomadic identity via ActivityPub a) because it was used as a development platform for just this and b) in order to be able to understand cloned nomadic ActivityPub actors elsewhere. This is also why it isn't possible to move from (streams) to Forte, to move from Forte to (streams) or to clone between (streams) and Forte.
(streams) itself doesn't require gateways to communicate with Mastodon & Co. either. It speaks three protocols natively: its own Nomad, Hubzilla's Zot6 and (optionally, but on by default) standard ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@silverpill Would be interesting to add Hubzilla's Zot6 and (streams)' Nomad (which would be Zot12 if it wasn't incompatible with Zot6) to the list.
By the way: Forte doesn't require a gateway to communicate with non-nomadic ActivityPub. A fully cloned Forte channel can communicate with a Mastodon account without jumping through hoops. Remember that Forte has almost fully-featured Hubzilla-level nomadic identity (i.e. everything except real-time syncing between channel instances; unlike Hubzilla and (streams) which do sync in real time, it needs a cronjob for that) directly built into its core.
(streams) does support nomadic identity via ActivityPub. But internally, it uses and relies upon Nomad for its nomadic identity. It only supports nomadic identity via ActivityPub a) because it was used as a development platform for just this and b) in order to be able to understand cloned nomadic ActivityPub actors elsewhere. This is also why it isn't possible to move from (streams) to Forte, to move from Forte to (streams) or to clone between (streams) and Forte.
(streams) itself doesn't require gateways to communicate with Mastodon & Co. either. It speaks three protocols natively: its own Nomad, Hubzilla's Zot6 and (optionally, but on by default) standard ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@silverpill Would be interesting to add Hubzilla's Zot6 and (streams)' Nomad (which would be Zot12 if it wasn't incompatible with Zot6) to the list.
By the way: Forte doesn't require a gateway to communicate with non-nomadic ActivityPub. A fully cloned Forte channel can communicate with a Mastodon account without jumping through hoops. Remember that Forte has almost fully-featured Hubzilla-level nomadic identity (i.e. everything except real-time syncing between channel instances; unlike Hubzilla and (streams) which do sync in real time, it needs a cronjob for that) directly built into its core.
(streams) does support nomadic identity via ActivityPub. But internally, it uses and relies upon Nomad for its nomadic identity. It only supports nomadic identity via ActivityPub a) because it was used as a development platform for just this and b) in order to be able to understand cloned nomadic ActivityPub actors elsewhere. This is also why it isn't possible to move from (streams) to Forte, to move from Forte to (streams) or to clone between (streams) and Forte.
(streams) itself doesn't require gateways to communicate with Mastodon & Co. either. It speaks three protocols natively: its own Nomad, Hubzilla's Zot6 and (optionally, but on by default) standard ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@silverpill Would be interesting to add Hubzilla's Zot6 and (streams)' Nomad (which would be Zot12 if it wasn't incompatible with Zot6) to the list.
By the way: Forte doesn't require a gateway to communicate with non-nomadic ActivityPub. A fully cloned Forte channel can communicate with a Mastodon account without jumping through hoops. Remember that Forte has almost fully-featured Hubzilla-level nomadic identity (i.e. everything except real-time syncing between channel instances; unlike Hubzilla and (streams) which do sync in real time, it needs a cronjob for that) directly built into its core.
(streams) does support nomadic identity via ActivityPub. But internally, it uses and relies upon Nomad for its nomadic identity. It only supports nomadic identity via ActivityPub a) because it was used as a development platform for just this and b) in order to be able to understand cloned nomadic ActivityPub actors elsewhere. This is also why it isn't possible to move from (streams) to Forte, to move from Forte to (streams) or to clone between (streams) and Forte.
(streams) itself doesn't require gateways to communicate with Mastodon & Co. either. It speaks three protocols natively: its own Nomad, Hubzilla's Zot6 and (optionally, but on by default) standard ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Forte #NomadicIdentity