#zot — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #zot, 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 -
Phew, I completed my migration from goharbor to #zot. But it was incredibly painful, because the zot documentation is really lacking.
I ended up reverse engineering a lot of the configs from their examples directory, source code, docs and alike.
The config valdation is also pain, because it only ever tells you one error at the time, which makes it quite time consuming.
And the most fun of it all: There can be HTTP errors with no error message in the logs.
Will see how it goes from now.
-
Phew, I completed my migration from goharbor to #zot. But it was incredibly painful, because the zot documentation is really lacking.
I ended up reverse engineering a lot of the configs from their examples directory, source code, docs and alike.
The config valdation is also pain, because it only ever tells you one error at the time, which makes it quite time consuming.
And the most fun of it all: There can be HTTP errors with no error message in the logs.
Will see how it goes from now.
-
Phew, I completed my migration from goharbor to #zot. But it was incredibly painful, because the zot documentation is really lacking.
I ended up reverse engineering a lot of the configs from their examples directory, source code, docs and alike.
The config valdation is also pain, because it only ever tells you one error at the time, which makes it quite time consuming.
And the most fun of it all: There can be HTTP errors with no error message in the logs.
Will see how it goes from now.
-
Phew, I completed my migration from goharbor to #zot. But it was incredibly painful, because the zot documentation is really lacking.
I ended up reverse engineering a lot of the configs from their examples directory, source code, docs and alike.
The config valdation is also pain, because it only ever tells you one error at the time, which makes it quite time consuming.
And the most fun of it all: There can be HTTP errors with no error message in the logs.
Will see how it goes from now.
-
Phew, I completed my migration from goharbor to #zot. But it was incredibly painful, because the zot documentation is really lacking.
I ended up reverse engineering a lot of the configs from their examples directory, source code, docs and alike.
The config valdation is also pain, because it only ever tells you one error at the time, which makes it quite time consuming.
And the most fun of it all: There can be HTTP errors with no error message in the logs.
Will see how it goes from now.
-
Kommt doch ins Grid!
👉Permalink
Wehklagen über Spam-Wellen, über unangemessene Postings, über Dauer-Repeater (Extrem-Booster) über mangelnde Berechtigungskontrolle über nicht wirklich funktionierende Inhaltswarnungen sind Teil des Fediverse. Dann auch noch das Beklagen über Zeichenbegrenzungen, unzureichende Formatierungsmöglichkeiten, eingeschränkte Umfragen, Beschränkungen mitgeschickter, oft nicht einbettbarer, sondern nur angehängter Bilder gehören auch dazu.Mein Rat: Kommt doch ins Grid!
Grid? Was ist das denn?
Das Grid ist der Netzwerkverbund aller Dienste, die Zot6/Nomad als Kommunikationsprotokoll verwenden. Aktuell sind das Hubzilla, (streams) und Zap (das zwar nicht wirklich weiterentwickelt wird... es gibt aber aktuell mindestens einen Hub, der mit Zap läuft).
Innerhalb des Grid greifen nicht nur die herausragenden Möglichkeiten des Berechtigungssystems vollständig, sondern der Zugriff auf beschränkte Ressourcen wird auch noch mittels magicAuth extrem komfortabel, weil der Nutzer sich gar nicht darum kümmern muss, seine Berechtigung für den Zugriff einer Ressource nachzuweisen. Läuft automatisch.
Hinzu kommt dann aber auch noch, dass viele der Vorteile des Berechtigungssystems auch auf die Interaktion mit dem ActivityPub-Fediverse wirken, sofern man sich nicht ausschließlich auf das Grid beschränkt.
Bei Hubzilla und (streams) hat man wirklich die Möglichkeit, ganz exakt festzulegen, wie man mit anderen Nutzern im Fediverse (Kanälen) interagiert. Ich gehe hier auf die Verfahrensweise mit Hubzilla ein, die vielleicht zunächst etwas komplizierter erscheint, aber trotzdem, wenn man es verstanden hat, recht einfach ist. Ich beschränke mich deshalb, weil es ausgesprochen unwahrscheinlich ist, dass irgendwer einen (streams)-Hub findet und sich dort registriert. Hubzilla zu nutzen ist in dieser Hinsicht wesentlich einfacher.Vordefinierte Rollen oder eigene Entscheidungen
Um seinen Stream (so nennt sich das, was bei anderen Diensten die "Timeline" heißt) sauber zu halten und Belästigungen zu vermeiden, muss man sich zunächst für eine Kanalrolle entscheiden. Foren lasse ich hier bewusst weg, denn die sind ein Spezialfall. Zur Auswahl stehen lediglich drei Varianten: Öffentlich, Persönlich und Benutzerdefiniert. Öffentlich und Persönlich sind bequem, weil einem damit einiges an Denkarbeit abgenommen wird. Allerdings beschränkt man sich damit auch in den Möglichkeiten.
Bei der Kanalrolle "Öffentlich" ist es Verbindungen (also diejenigen, die einem selbst folgen und denen man ebenfalls folg, aber auch jedem im Internet) grundsätzlich erlaubt, unsere öffentlichen Postings zu sehen (in ihrem Stream/ihrer Timeline), unser Standardprofil, unsere Verbindungen, unsere öffentlichen Dateien (Bilder, Dokumente etc.) und unsere Web- und Wikiseiten zu sehen. Außerdem dürfen Verbindungen unsere Beiträge kommentieren, liken/disliken, uns Direktnachrichten schicken, Inhalte unseres Profils liken/disliken und mit uns chatten.
Diese Rechte können wir den Verbindungen (außer wir schränken bestimmte einzelne Inhalte im Zugriff explizit ein) auch nicht verwehren.
Es fällt auf, dass wir selbst es mit diesen Berechtigungen unseren Verbindungen nicht erlauben, uns Postings zu schicken. Wir sehen damit also in unserem Stream nicht, was die Verbindung selbst öffentlich gepostet hat. Damit wäre die Verbindung also nur sowas wie ein "Follower" (wie man es von anderen Diensten kennt). Es muss also noch eine weitere Möglichkeit geben, unseren Verbindungen dieses zu erlauben, damit wir mit unserem Kanal auch ein "richtiges" Social-Network-Erlebnis haben.
Die Berechtigungen, die ich eben beschrieben habe, sind die Berechtigungen der Kanalrollen. Sie beziehen sich also auf unserem Kanal. Es gibt aber auch noch die Kontaktrolle, welche unsere Verbindungen betrifft. In dieser können zusätzliche Berechtigungen eingeräumt werden (aber keine Berechtigungen der Kanalrolle wieder entzogen werden).
Zu jeder Kanalrolle gibt es immer eine Standard-Kontaktrolle. Bei der Kanalrolle "Öffentlich" erlaubt diese Standard-Kontaktrolle unseren Verbindungen, uns ihre Beiträge in unseren Stream zu schicken. Die werden damit also auch "followed". Zusätzlich erteilt die Standard-Kontaktrolle unseren Verbindungen auch noch das Wall-to-Wall-Posting und das Spiegeln unserer Beiträge in einem anderen Kanal. Auf diese beiden Spezialfälle gehe ich jetzt hier nicht ein. Wir ignorieren sie einfach erstmal.
Ein Kanal mit der Kanalrolle "Öffentlich" verhält sich also genau so, wie man das von ganz normalen Social-Network-Accounts erwartet.
Hinweis: Alles, was wir mit einem solchen Kanal veröffentlichen, wird auch öffentlich geteilt, sofern wir dies nicht für eine einzelne Ressource explizit anders festlegen.
Bei der Kanalrolle "Persönlich" ist es grundsätzlich erlaubt, unsere öffentlichen Postings (als "Follower") und unser Standard-Profil zu sehen. Ebenso unsere öffentlich geteilten Dateien, Webseiten und Wikis. Mehr nicht!
Auch "Persönlich" hat eine spezielle Standard-Kontaktrolle. Diese erlaubt es Verbindungen zusätzlich , uns Beiträge in unseren Stream zu schicken ("Followed") und unsere Verbindungen zu sehen.
Beachte: Alles, was wir mit einem solchen Kanal veröffentlichen ist nicht öffentlich, also nur für unsere Verbindungen zu sehen, sofern wir die Ressource nicht explizit als "öffentlich" veröffentlichen. Das ist ein entscheidender Unterschied zur Kanalrolle "Öffentlich".
Das Verhalten, dass bei der Kanalrolle "Persönlich" grundsätzlich erstmal nur an Verbindungen und damit nicht-öffentlich geteilt wird, liegt nicht an der Kanalrolle und auch nicht an der Standrad-Kontaktrolle, sondern am Mechanismus der Privacy Gruppen.
Auch wenn die App "Privacy Gruppen" nicht installiert ist, verfügt jeder Kanal über eine Privacy Gruppe namens "Freunde". Alle neuen Verbindungen werden dieser Privacy Gruppe automatisch zugewiesen. Bei der Kanalrolle "Öffentlich" hat das keine direkten Auswirkungen. Sehr wohl aber bei der Kanalrolle "Persönlich". Hier ist die Privacy Gruppe "Freunde" nämlich so konfiguriert, dass alles, was wir teilen grundsätzlich nur an Mitglieder dieser Gruppe geteilt wird. Das bewirkt, dass wir nicht-öffentlich teilen, es sei denn, wir stellen das für eine einzelne Ressource explizit ein.
Die dritte Kanalrolle, "Benutzerdefiniert" ist die flexibelste und auch diejenige, die man auswählen sollte, wenn man wirklich alle Unzulänglichkeiten unterbinden möchte, die andere Fediverse-Dienste aufweisen.
"Benutzerdefiniert" bedeutet, dass man auch die Kanalrolle in allen Berechtigungen selbst einstellen kann. In der Grundeinstellung, also wenn man einen Kanal mit dieser Rolle frisch erstellt hat, entspricht die Kanalrolle des Rolle "Persönlich", erlaubt aber grundsätzlich auch, dass Dritte unsere Verbindungen sehen können. Die Standard-Verbindungsrolle entspricht 1:1 der Verbindungsrolle "Persönlich". Die Privacy-Gruppe "Freunde" ist hingegen wieder so eingestellt, dass grundsätzlich öffentlich geteilt wird.Eigene Entscheidungen
Wer nun also von seinem Social-Network-Dienst mehr möchte, als 08/15, muss Entscheidungen treffen, also ein wenig Hirnschmalz investieren. Ohne das geht es nicht... weder bei Hubzilla, noch bei irgendeinem anderen System, denn dieses weiß ja nicht, kann ja nicht ahnen, was wir möchten. Das müssen wir schon selbst wissen oder uns klarmachen. Wer das nicht will, muss halt mit den vordefinierten Rollen leben, die auch schon vieles besser machen, als bei manchem anderen System und die -- aufgrund der vorhandenen Mechanismen -- durchaus gewisse Dinge unterbinden können.
Möchte man aber kein System "von der Stange", sind einige Vorüberlegungen und Einstellungen notwendig.
Zunächst einmal hier die einzelnen Berechtigungen, die Hubzilla zur Konfiguration anbietet:- Kann meinen Kanal-Stream und meine Beiträge sehen
- Kann mir die Beiträge aus seinem Kanal schicken
- Kann mein Standardprofil sehen
- Kann meine Verbindungen sehen
- Kann meine Datei- und Bilderordner sehen
- Kann in meine Datei- und Bilderordner hochladen/ändern
- Kann die Webseiten meines Kanals sehen
- Kann meine Wiki-Seiten sehen
- Kann Webseiten in meinem Kanal erstellen/ändern
- Kann meine Wiki-Seiten bearbeiten
- Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen
- Darf meine Beiträge kommentieren und mögen/nicht mögen
- Kann mir direkte Nachrichten schicken
- Kann Profile und Profilsachen mögen/nicht mögen
- Kann mit mir chatten
- Kann meine öffentlichen Beiträge in anderen Kanälen zitieren/spiegeln
- Kann meinen Kanal administrieren
Etliche dieser Berechtigungen erklären sich von selbst, einige sind vielleicht nicht so klar und einige wenige kann man falsch verstehen. Im Anhang gibt es eine Tabelle, in der genauer erklärt wird, was sich hinter den Berechtigungen verbirgt.
Diese Berechtigungen sind das WAS, also was andere mit Inhalten/Ressourcen unseres Kanals tun können.
Dazu gehört dann aber auch noch das WER! Damit legen wir fest, wem bestimmte Dinge erlaubt bzw. verboten sind:- Jeder im Internet
- Jeder authentifizierte
- Alle Hubzilla-Mitglieder
- Jeder auf dieser Webseite
- Beliebige Verbindungen
- Angenommene Verbindungen
- Nur die, denen Du es explizit erlaubst
- Nur ich
Auch hier gibt es einige "Wers", die etwas näher erläutert werden müssen. Dafür gibt es ebenfalls eine kleine Tabelle im Anhang.
Die Wichtigsten Adressaten für Berechtigungen sind: "Jeder im Internet" und "Nur die, denen Du es explizit erlaubst".
Nun ist es an der Zeit, sich Gedanken darüber zu machen, was man wem denn nun erlauben möchte. Dafür arbeitet man einfach die einzelnen Berechtigungen hintereinander ab und legt die Berechtigten fest.
Im Hauptmenü (das Menü, welches sich hinter unserem Avatarbild versteckt) wählt man
Einstellungen ➔ Kanal-Einstellungen
und legt im Abschnitt Grundeinstellungen die gewünschte Kanalrolle (Channel Role) fest. Also für unsere Zwecke "Benutzerdefiniert".
Nun wechselt man zu Einstellungen ➔ Privacy-Einstellungen
Die Grundeinstallungen dort sind selbsterklärend und sollten nach den eigenen Wünschen festgelegt werden. Wichtig ist hier die einzige "nicht selbsterklärende" Einstellung "Enable OCAP access". Dies ermöglicht, dass Medien (Bilder etc.) auch dann in einem Thread angezeigt werden, wenn diese eigentlich im Zugriff eingeschränkt sind. Wird diese Option nicht gewählt, kann es vorkommen, dass man eingebettete Bilder in manchen Threads nicht sieht. Meine Empfehlung: Option einschalten!
Die eigentliche Einstellung der Berechtigungen, die unser Kanal einräumt, findet man unter dem Button "Benutzerdefinierte Konfiguration der Channel Role" (dies wird bei den Kanalrollen "Öffentlich" und "Persönlich" nicht angezeigt, weil man diese dort nicht ändern kann).
Es wird eine Warnung angezeigt, die zwar berechtigt ist, aber wir WISSEN ja, was wir tun wollen.Die sorgfältig konfigurierte Kanalrolle
Deshalb klicken wir auf den Button "Risiko akzeptieren und weitermachen" und landen im Formular für die genannten Berechtigungen. Die können wir nun nach unseren Wünschen und nachdem wir uns Gedanken gemacht haben, entsprechend konfigurieren.
Dabei aber immer daran denken: Die Berechtigung, die wir hier erteilen, können wir generell nicht zurücknehmen. Wir können sie höchstens in Einzelfällen "übersteuern", indem wir Inhalte/Ressourcen über die Berechtigungs-Einstellungen bestimmten Verbindungen zugänglich machen.
Es ist also ausgesprochen sinnvoll, bei der Kanalrolle so wenig freizügige Berechtigungen zu vergeben, wie möglich und nur so viele, wie für den Zweck absolut nötig.
Bedenkt: Nur was Ihr für "Jeder im Internet" erlaubt, kann auch wirklich öffentlich gesehen werden. Die spezielleren Berechtigungen sind eher etwas für Spezialfälle. "Nur die, denen Du es explizit erlaubst" wirkt sich hingegen ausschließlich auf Verbindungen aus.
Bedeutet: Alles, was wirklich jeder im Internet sehen können soll, bekommt "Jeder im Internet" (bei einem typischen öffentlichen Social-Network-Kanal) sind das "Kann meinen Kanal-Stream und meine Beiträge sehen", "Kann mein Standardprofil sehen" und "Kann meine Datei- und Bilderordner sehen". Wer öffentlich Wiki- oder Webseiten anbietet, erlaubt auch das Anschauen dieser durch jeden im Internet.
Den Rest kann man dann ruhigen Gewissens auf "Nur die, denen Du es explizit erlaubst" setzen. Damit können sich die Berechtigungen nur auf die eigenen Verbindungen auswirken.Die passenden Kontaktrollen
Euch muss an dieser Stelle bewusst sein, dass die Standard-Kontaktrolle sehr viele zusätzlich Berechtigungen vergibt:
Diese Kontaktrolle kann man durchaus nutzen, um ein eher "klassisches" Social-Network-Verhalten für bestimmte Verbindungen zu erhalten.
Wenn man aber wirkliche Kontrolle haben möchte, muss man sich für andere Verbindungen weitere Kontaktrollen erstellen."Follower"
Sinnvoll wäre z.B. als neuer Standard für neue Verbindungen die Rolle "Follower". Diese erstellen wir, setzen die Option "Neuen Kontakten automatisch diese Rolle zuweisen" (damit wird die Option aus der Standard-Kontaktrolle gelöscht) und geben keine weiteren Berechtigungen, außer "Darf meine Beiträge kommentieren und mögen/nicht mögen". Damit verfügen Verbindungen mit dieser Kontaktrolle nur die in der Kanalrolle vergebenen Berechtigungen plus die Möglichkeit zum Kommentieren und liken/disliken. Wenn sich jemand mit Eurem Kanal verbindet, dann verhält er sich wie ein reiner Follower. Diese Kontaktrolle ist sinnvoll, wenn Ihr es anderen gestatten möchtet, Euch zu folgen.
Wenn Ihr meint, solche "Follower" sollten auch Eure Verbindungen anschauen können, gewährt Ihr zusätzlich halt auch diese Berechtigung."Followed"
Die nächste sinnvolle Kontaktrolle könnte dann z.B. "Followed" genannt werden. Dieser Rolle räumt Ihr dann, zusätzlich zu den Berechtigungen von "Follower", noch "Kann mir die Beiträge aus seinem Kanal schicken" ein, damit Ihr auch die Beiträge der Verbindung in Eurem Stream sehen könnt. Damit es sich auch "echt" anfühlt, wären hier auch noch die Berechtigungen "Kann mir direkte Nachrichten schicken", "Kann Profile und Profilsachen mögen/nicht mögen" und "Kann mit mir chatten" praktikabel.
Diese Kontaktrolle vergebt Ihr dann, wenn Ihr selbst eine Verbindung zu einem fremden Kanal herstellt... und an Kanäle, die Euch eine Kontaktanfrage schicken und denen Ihr "zurückfolgen" möchtet."Followed+"
Eine Weitere Kontaktrolle würde ich "Followed+" nennen. Die ist für Kontakte aus dem Grid, und von den owa-fähigen Deinsten Forte und Friendica. Diesen kann man die zusätzliche Berechtigung "Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen" erteilen (wenn man denn möchte). Das Wall-to-Wall-Posting ist eine spezielle Art, Postings zu veröffentlichen. Wen eine unserer Verbindung ein Wall-Posting auf unserem Kanal veröffentlicht, dann erscheint dieses Posting in unserem Kanalstream. Es ist also in unserem Kanal veröffentlicht.Mehr
Für gute Freunde, verwandte, Mitglieder eines Teams, Vereins etc. kann man dann, je nach Notwendigkeit noch weitere Berechtigungen vergeben und für jede erdenkliche Art von Verbindungen ganz exakt zugeschnittene Kontaktrollen erstellen.Privacy Gruppen für genauere Steuerung
Privacy Gruppen sind Gruppen von Verbindungen, mit denen man das Teilen von Inhalten steuern kann. Sie ähneln dem, was man bei Google+ als "Kreise" kannte und was bei Diaspora* als "Aspekte" existiert. Möchte man einen Inhalt an eine bestimmte Gruppe von Verbindungen teilen, so kann man diese Verbindungen in eine Gruppe einfügen und mit den Berechtigungs-Einstellungen festlegen, dass der Inhalt ausschließlich mit den Gruppenmitgliedern geteilt wird. Das macht eine geschlossene Gruppenkommunikation möglich.
Eine weitere praktische Anwendung von Privacy Gruppen ist das zuteilen von Kontaktrollen auf einen Rutsch. Wenn man eine Kontaktrolle in der App "Contact Roles" öffnet, kann man auswählen, dass diese Kontaktrolle allen Gruppenmitgliedern einer Privacy Gruppe zugewiesen wird. Beachte: Das wirkt sich nur auf Verbindungen aus, die sich zu diesem Zeitpunkt bereits in der Privacy Gruppe befanden. Auf später hinzugefügte Verbindungen wirkt es sich nicht aus. Hier muss man ggf. die Gruppen-Zuweisung wiederholen.Die Repeat-Hölle verlassen
Es gibt Nutzer im Fediverse, die wirklich exzessiv "Boosten/Repeaten". Trotzdem mag man diesen Nutzern folgen, weil die wenigen (oder vielleicht nicht einmal wenigen) ihrer eigenen Postings insteressant sind und man sie in seinem Stream finden möchte. Aber es kommt zu viel "Rauschen" herein, weil halt auch zu viel wiederholt wird. Bei Hubzilla ist es kein Problem, diese Repeats loszuwerden, ohne die "echten" Postings zu verlieren. Man kann für jede Verbindung einen Filter einrichten, der z.B. Repeats der Verbindung nicht in den Stream importiert.
Dafür öffnet man aus der App "Verbindungen" heraus den Verbindungs-Editor (kleines Bleistift-Symbol) und trägt im Tab "Filter für den Inhalt" im Feld "Beiträge mit diesem Text nicht importieren" die Zeile?verb == Announce
ein. Damit werden Repeats (Wiederholungen / Boosts) von dieser Verbindung nicht mehr in den eigenen Stream importiert.Kanalfilter
Neben den eben erwähnten Kontaktfiltern gibt es auch noch Kanalfilter, die sich auf den gesamten Kanal auswirken. Auch hier könnte man z.B. die Zeile zur Repeat-Unterdrückung unterbringen. Das würde dann aber bewirken, dass gar keine Repeats mehr im Kanal erscheinen, also auch solche nicht, die vielleicht erwünscht sind.
Kanalfilter findet man unter Einstellungen ➔ Kanal-Einstellungen ➔ Beiträge mit diesem Text nicht importierenInhaltswarnung
Während bei den meisten Diensten im Fediverse der Verfasser dafür verantwortlich gemacht wird, bestimmte Inhalte hinter einer Inhaltswarnung zu verstecken, funktioniert Hubzilla genau anders herum. Hier legt der Empfänger fest, was ihn "triggern" könnte oder was ihn "nervt". Das ist eigentlich auch ausgesprochen sinnvoll, weil ich selbst am besten weiß, was ich nicht sofort in meinem Stream sehen möchte. Wenn der Absender dafür verantwortlich ist, muss er ja erahnen, was ich nicht sehen möchte... und verbirgt solche Inhalte dann zwangsweise auch vor anderen Nutzern, die davor aber gar nicht gewarnt werden möchten.
Wer sich mit Hubzilla also vor bestimmten Inhalten schützen möchte, installiert die App "NSFW". Das ist eine einfache Filter-App, in welcher man eingeben kann, bei welchen Inhalten ein Posting zunächst ausgeblendet hinter einer Schaltfläche verborgen bleibt. Es kommt also nicht darauf an, das der Absender errät, was ich nicht sehen möchte und eine Inhaltswarnung verwendet (die sich dann auch auf alle auswirkt, die seinen Beitrag anschauen), sondern darauf, dass ich als Empfänger festlege, was verborgen werden soll.
Bewege ich mich also nur im Grid und habe auch nur Verbindungen zum Grid, muss ich mich um die Befindlichkeiten anderer nicht kümmern. Sobald man aber auch Teil des Fediverse wird, hilft unseren "NSFW"-App nicht weiter, denn die meisten anderen Dienste haben diesen Mechanismus nicht. Möchten wir also rücksichtsvoll vorgehen, müssen wir doch auch für andre mitdenken und erraten, was irgendwen in der weiten Welt "triggern" könnte.
Und das Ausblenden eines solchen Eintrags verwirklichen wir dann einfach, indem wir das Zusammenfassungsfeld (Summary) im Beitragseditor z.B. mit "Inhaltswarnung" befüllen. Nun sind auch nutzer anderer Dienste "geschützt".
Nun aber ein Spezialfall:
Es ist allgemein bekannt, dass viele sich entsetzt schütteln, wenn sie in einem Posting von Dieter Bohlen angestarrt werden (mir selbst geht es nicht so... ich mag ihn... zu erklären weshalb, würde hier aber zu weit führen). Nun wollen wir ein Posting verfassen, in welchem ein Bild von D. B. eingebunden ist. Um Nutzer aus dem Grid zu schützen, müsste ich z.B. das Wort "Bohlen" im Text unterbringen, und schon wären alle "gerettet", die in "NSFW" dieses Wort als Filter haben.
Aber angenommen, wir wollen nur das Bild selbst ausblenden und ahnen, dass es Nutzer gibt, die gerne mit Holz arbeiten und deshalb das Wort "Bohlen" auch nicht als Inhaltswarnung im Filter haben. Nun, dann können wir das Bild bei Hubzilla einfach zwischen die Tags[spoiler][/spoiler]packen. Funktioniert prima! Nur... für Mastodon-Nutzer funktioniert das nicht. Mastodon (und viele andere Fediverse-Dienste) kennen keinen extra Spoiler. Hinzu kommt das bei vielen dieser Dienste Bilder gar nicht in ein Posting eingebunden werden, sondern als Anhang am Posting dranhängen. Selbst wenn sie das Spoiler-Tag kennen würden, würde der Empfänger das Gesicht von D. B. wieder sehen, weil es außerhalb des Postings unten dranhängt.
Aber ehrlich... das soll echt nicht UNSER Problem sein. Wir können alles dafür tun, dass bestimmte Inhalte verborgen bleiben, aber nichts daran ändern, wenn andere Dienste das nicht richtig verarbeiten.
Abgesehen davon ist es möglich auch Teile eines Postings zunächst zu verbergen (BTW: beliebig viele Teile), indem man das Spoiler-Tag verwendet. Funktioniert aber zuverlässig halt nur im Grid.Zeichenbegrenzung
Na ja, was soll man sagen?
Hubzilla packt an die 16 Millionen Zeichen. Dieser Artikel hier ist also ein Fliegenschiss mit ca. 24.000 Zeichen. ;-)Textgestaltung
BBcode "Hubzilla-Flavour" bietet umfangreiche Textgestaltungsmöglichkeiten. Leider werden diese vom derzeitigen Beitragseditor nicht alle vereinfacht z.B. über Buttons und Dialoge angeboten. Hier müsste dringend noch nachgebessert werden (könnte mein nächstes Projekt werden). Zumindest verfügt der Editor über eine Autovervollständigung, die hilfreich ist, wenn man weiß, was die BBcode Tags bewirken.
Was Hubzilla von vielen Diensten unterscheidet ist, dass Medien wirklich in den Beitrag eingebettet werden, also an der Stelle erscheinen, wo wir sie unterbringen. Die Anzahl an Medien ist außerdem ebenfalls nicht beschränkt.
Bedenkt aber, wenn Ihr Beiträge ins Fediverse teilt, dass es Dienste gibt, die nicht nur Medien (also z.B. Bilder) hinten anhängen, sondern auch auf wenige (bei Mastodon vier) begrenzen. Es ist deshalb sinnvoll, einen Hinweis auf die tatsächliche Anzahl von Bildern hinzuweisen und dass es erforderlich sein kann, das Original-Posting auf Eurer Heimat-Instanz zu besuchen, um alle Bilder (und die auch noch korrekt eingebettet) sehen zu können. Klingt komisch, ist aber so. ;-) :-DFazit
Kommt einfach ins Grid! Besorgt euch einen Account bei Hubzilla. Ihr könnt das ja zusätzlich zu Eurem aktuellen Fediverse-Account tun. Und importiert Eure Follower-/Following-Liste. Dafür gibt es (sofern der von Euch gewählte Hub das Addon installiert hat) inzwischen ein Addon, das die typischen Exportdateien (csv) von Mastodon und co. verarbeitet. Richtet Euren Kanal so ein, wie Ihr es euch vorstellt und nutzt es.
Es ist durchaus möglich, dass Ihr dann irgendwann immer öfter mit Hubzilla, statt mit dem ursprünglichen Dienst im Fediverse unterwegs seid. Und wenn Ihr dann auch noch Kontakte zu Nutzern im Grid habt, werdet Ihr feststellen, dass die soziale Interaktion damit noch viel komfortabler ist. Vielleicht wagt ja dann irgendwann auch die eine oder andere eurer alten Verbindungen auch den Schritt und Ihr könnt den Komfort gemeinsam genießen.
Anhänge
Wer?
Was?
#hubzilla #zot #nomad #grid #fediverse -
Kommt doch ins Grid!
👉Permalink
Wehklagen über Spam-Wellen, über unangemessene Postings, über Dauer-Repeater (Extrem-Booster) über mangelnde Berechtigungskontrolle über nicht wirklich funktionierende Inhaltswarnungen sind Teil des Fediverse. Dann auch noch das Beklagen über Zeichenbegrenzungen, unzureichende Formatierungsmöglichkeiten, eingeschränkte Umfragen, Beschränkungen mitgeschickter, oft nicht einbettbarer, sondern nur angehängter Bilder gehören auch dazu.Mein Rat: Kommt doch ins Grid!
Grid? Was ist das denn?
Das Grid ist der Netzwerkverbund aller Dienste, die Zot6/Nomad als Kommunikationsprotokoll verwenden. Aktuell sind das Hubzilla, (streams) und Zap (das zwar nicht wirklich weiterentwickelt wird... es gibt aber aktuell mindestens einen Hub, der mit Zap läuft).
Innerhalb des Grid greifen nicht nur die herausragenden Möglichkeiten des Berechtigungssystems vollständig, sondern der Zugriff auf beschränkte Ressourcen wird auch noch mittels magicAuth extrem komfortabel, weil der Nutzer sich gar nicht darum kümmern muss, seine Berechtigung für den Zugriff einer Ressource nachzuweisen. Läuft automatisch.
Hinzu kommt dann aber auch noch, dass viele der Vorteile des Berechtigungssystems auch auf die Interaktion mit dem ActivityPub-Fediverse wirken, sofern man sich nicht ausschließlich auf das Grid beschränkt.
Bei Hubzilla und (streams) hat man wirklich die Möglichkeit, ganz exakt festzulegen, wie man mit anderen Nutzern im Fediverse (Kanälen) interagiert. Ich gehe hier auf die Verfahrensweise mit Hubzilla ein, die vielleicht zunächst etwas komplizierter erscheint, aber trotzdem, wenn man es verstanden hat, recht einfach ist. Ich beschränke mich deshalb, weil es ausgesprochen unwahrscheinlich ist, dass irgendwer einen (streams)-Hub findet und sich dort registriert. Hubzilla zu nutzen ist in dieser Hinsicht wesentlich einfacher.Vordefinierte Rollen oder eigene Entscheidungen
Um seinen Stream (so nennt sich das, was bei anderen Diensten die "Timeline" heißt) sauber zu halten und Belästigungen zu vermeiden, muss man sich zunächst für eine Kanalrolle entscheiden. Foren lasse ich hier bewusst weg, denn die sind ein Spezialfall. Zur Auswahl stehen lediglich drei Varianten: Öffentlich, Persönlich und Benutzerdefiniert. Öffentlich und Persönlich sind bequem, weil einem damit einiges an Denkarbeit abgenommen wird. Allerdings beschränkt man sich damit auch in den Möglichkeiten.
Bei der Kanalrolle "Öffentlich" ist es Verbindungen (also diejenigen, die einem selbst folgen und denen man ebenfalls folg, aber auch jedem im Internet) grundsätzlich erlaubt, unsere öffentlichen Postings zu sehen (in ihrem Stream/ihrer Timeline), unser Standardprofil, unsere Verbindungen, unsere öffentlichen Dateien (Bilder, Dokumente etc.) und unsere Web- und Wikiseiten zu sehen. Außerdem dürfen Verbindungen unsere Beiträge kommentieren, liken/disliken, uns Direktnachrichten schicken, Inhalte unseres Profils liken/disliken und mit uns chatten.
Diese Rechte können wir den Verbindungen (außer wir schränken bestimmte einzelne Inhalte im Zugriff explizit ein) auch nicht verwehren.
Es fällt auf, dass wir selbst es mit diesen Berechtigungen unseren Verbindungen nicht erlauben, uns Postings zu schicken. Wir sehen damit also in unserem Stream nicht, was die Verbindung selbst öffentlich gepostet hat. Damit wäre die Verbindung also nur sowas wie ein "Follower" (wie man es von anderen Diensten kennt). Es muss also noch eine weitere Möglichkeit geben, unseren Verbindungen dieses zu erlauben, damit wir mit unserem Kanal auch ein "richtiges" Social-Network-Erlebnis haben.
Die Berechtigungen, die ich eben beschrieben habe, sind die Berechtigungen der Kanalrollen. Sie beziehen sich also auf unserem Kanal. Es gibt aber auch noch die Kontaktrolle, welche unsere Verbindungen betrifft. In dieser können zusätzliche Berechtigungen eingeräumt werden (aber keine Berechtigungen der Kanalrolle wieder entzogen werden).
Zu jeder Kanalrolle gibt es immer eine Standard-Kontaktrolle. Bei der Kanalrolle "Öffentlich" erlaubt diese Standard-Kontaktrolle unseren Verbindungen, uns ihre Beiträge in unseren Stream zu schicken. Die werden damit also auch "followed". Zusätzlich erteilt die Standard-Kontaktrolle unseren Verbindungen auch noch das Wall-to-Wall-Posting und das Spiegeln unserer Beiträge in einem anderen Kanal. Auf diese beiden Spezialfälle gehe ich jetzt hier nicht ein. Wir ignorieren sie einfach erstmal.
Ein Kanal mit der Kanalrolle "Öffentlich" verhält sich also genau so, wie man das von ganz normalen Social-Network-Accounts erwartet.
Hinweis: Alles, was wir mit einem solchen Kanal veröffentlichen, wird auch öffentlich geteilt, sofern wir dies nicht für eine einzelne Ressource explizit anders festlegen.
Bei der Kanalrolle "Persönlich" ist es grundsätzlich erlaubt, unsere öffentlichen Postings (als "Follower") und unser Standard-Profil zu sehen. Ebenso unsere öffentlich geteilten Dateien, Webseiten und Wikis. Mehr nicht!
Auch "Persönlich" hat eine spezielle Standard-Kontaktrolle. Diese erlaubt es Verbindungen zusätzlich , uns Beiträge in unseren Stream zu schicken ("Followed") und unsere Verbindungen zu sehen.
Beachte: Alles, was wir mit einem solchen Kanal veröffentlichen ist nicht öffentlich, also nur für unsere Verbindungen zu sehen, sofern wir die Ressource nicht explizit als "öffentlich" veröffentlichen. Das ist ein entscheidender Unterschied zur Kanalrolle "Öffentlich".
Das Verhalten, dass bei der Kanalrolle "Persönlich" grundsätzlich erstmal nur an Verbindungen und damit nicht-öffentlich geteilt wird, liegt nicht an der Kanalrolle und auch nicht an der Standrad-Kontaktrolle, sondern am Mechanismus der Privacy Gruppen.
Auch wenn die App "Privacy Gruppen" nicht installiert ist, verfügt jeder Kanal über eine Privacy Gruppe namens "Freunde". Alle neuen Verbindungen werden dieser Privacy Gruppe automatisch zugewiesen. Bei der Kanalrolle "Öffentlich" hat das keine direkten Auswirkungen. Sehr wohl aber bei der Kanalrolle "Persönlich". Hier ist die Privacy Gruppe "Freunde" nämlich so konfiguriert, dass alles, was wir teilen grundsätzlich nur an Mitglieder dieser Gruppe geteilt wird. Das bewirkt, dass wir nicht-öffentlich teilen, es sei denn, wir stellen das für eine einzelne Ressource explizit ein.
Die dritte Kanalrolle, "Benutzerdefiniert" ist die flexibelste und auch diejenige, die man auswählen sollte, wenn man wirklich alle Unzulänglichkeiten unterbinden möchte, die andere Fediverse-Dienste aufweisen.
"Benutzerdefiniert" bedeutet, dass man auch die Kanalrolle in allen Berechtigungen selbst einstellen kann. In der Grundeinstellung, also wenn man einen Kanal mit dieser Rolle frisch erstellt hat, entspricht die Kanalrolle des Rolle "Persönlich", erlaubt aber grundsätzlich auch, dass Dritte unsere Verbindungen sehen können. Die Standard-Verbindungsrolle entspricht 1:1 der Verbindungsrolle "Persönlich". Die Privacy-Gruppe "Freunde" ist hingegen wieder so eingestellt, dass grundsätzlich öffentlich geteilt wird.Eigene Entscheidungen
Wer nun also von seinem Social-Network-Dienst mehr möchte, als 08/15, muss Entscheidungen treffen, also ein wenig Hirnschmalz investieren. Ohne das geht es nicht... weder bei Hubzilla, noch bei irgendeinem anderen System, denn dieses weiß ja nicht, kann ja nicht ahnen, was wir möchten. Das müssen wir schon selbst wissen oder uns klarmachen. Wer das nicht will, muss halt mit den vordefinierten Rollen leben, die auch schon vieles besser machen, als bei manchem anderen System und die -- aufgrund der vorhandenen Mechanismen -- durchaus gewisse Dinge unterbinden können.
Möchte man aber kein System "von der Stange", sind einige Vorüberlegungen und Einstellungen notwendig.
Zunächst einmal hier die einzelnen Berechtigungen, die Hubzilla zur Konfiguration anbietet:- Kann meinen Kanal-Stream und meine Beiträge sehen
- Kann mir die Beiträge aus seinem Kanal schicken
- Kann mein Standardprofil sehen
- Kann meine Verbindungen sehen
- Kann meine Datei- und Bilderordner sehen
- Kann in meine Datei- und Bilderordner hochladen/ändern
- Kann die Webseiten meines Kanals sehen
- Kann meine Wiki-Seiten sehen
- Kann Webseiten in meinem Kanal erstellen/ändern
- Kann meine Wiki-Seiten bearbeiten
- Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen
- Darf meine Beiträge kommentieren und mögen/nicht mögen
- Kann mir direkte Nachrichten schicken
- Kann Profile und Profilsachen mögen/nicht mögen
- Kann mit mir chatten
- Kann meine öffentlichen Beiträge in anderen Kanälen zitieren/spiegeln
- Kann meinen Kanal administrieren
Etliche dieser Berechtigungen erklären sich von selbst, einige sind vielleicht nicht so klar und einige wenige kann man falsch verstehen. Im Anhang gibt es eine Tabelle, in der genauer erklärt wird, was sich hinter den Berechtigungen verbirgt.
Diese Berechtigungen sind das WAS, also was andere mit Inhalten/Ressourcen unseres Kanals tun können.
Dazu gehört dann aber auch noch das WER! Damit legen wir fest, wem bestimmte Dinge erlaubt bzw. verboten sind:- Jeder im Internet
- Jeder authentifizierte
- Alle Hubzilla-Mitglieder
- Jeder auf dieser Webseite
- Beliebige Verbindungen
- Angenommene Verbindungen
- Nur die, denen Du es explizit erlaubst
- Nur ich
Auch hier gibt es einige "Wers", die etwas näher erläutert werden müssen. Dafür gibt es ebenfalls eine kleine Tabelle im Anhang.
Die Wichtigsten Adressaten für Berechtigungen sind: "Jeder im Internet" und "Nur die, denen Du es explizit erlaubst".
Nun ist es an der Zeit, sich Gedanken darüber zu machen, was man wem denn nun erlauben möchte. Dafür arbeitet man einfach die einzelnen Berechtigungen hintereinander ab und legt die Berechtigten fest.
Im Hauptmenü (das Menü, welches sich hinter unserem Avatarbild versteckt) wählt man
Einstellungen ➔ Kanal-Einstellungen
und legt im Abschnitt Grundeinstellungen die gewünschte Kanalrolle (Channel Role) fest. Also für unsere Zwecke "Benutzerdefiniert".
Nun wechselt man zu Einstellungen ➔ Privacy-Einstellungen
Die Grundeinstallungen dort sind selbsterklärend und sollten nach den eigenen Wünschen festgelegt werden. Wichtig ist hier die einzige "nicht selbsterklärende" Einstellung "Enable OCAP access". Dies ermöglicht, dass Medien (Bilder etc.) auch dann in einem Thread angezeigt werden, wenn diese eigentlich im Zugriff eingeschränkt sind. Wird diese Option nicht gewählt, kann es vorkommen, dass man eingebettete Bilder in manchen Threads nicht sieht. Meine Empfehlung: Option einschalten!
Die eigentliche Einstellung der Berechtigungen, die unser Kanal einräumt, findet man unter dem Button "Benutzerdefinierte Konfiguration der Channel Role" (dies wird bei den Kanalrollen "Öffentlich" und "Persönlich" nicht angezeigt, weil man diese dort nicht ändern kann).
Es wird eine Warnung angezeigt, die zwar berechtigt ist, aber wir WISSEN ja, was wir tun wollen.Die sorgfältig konfigurierte Kanalrolle
Deshalb klicken wir auf den Button "Risiko akzeptieren und weitermachen" und landen im Formular für die genannten Berechtigungen. Die können wir nun nach unseren Wünschen und nachdem wir uns Gedanken gemacht haben, entsprechend konfigurieren.
Dabei aber immer daran denken: Die Berechtigung, die wir hier erteilen, können wir generell nicht zurücknehmen. Wir können sie höchstens in Einzelfällen "übersteuern", indem wir Inhalte/Ressourcen über die Berechtigungs-Einstellungen bestimmten Verbindungen zugänglich machen.
Es ist also ausgesprochen sinnvoll, bei der Kanalrolle so wenig freizügige Berechtigungen zu vergeben, wie möglich und nur so viele, wie für den Zweck absolut nötig.
Bedenkt: Nur was Ihr für "Jeder im Internet" erlaubt, kann auch wirklich öffentlich gesehen werden. Die spezielleren Berechtigungen sind eher etwas für Spezialfälle. "Nur die, denen Du es explizit erlaubst" wirkt sich hingegen ausschließlich auf Verbindungen aus.
Bedeutet: Alles, was wirklich jeder im Internet sehen können soll, bekommt "Jeder im Internet" (bei einem typischen öffentlichen Social-Network-Kanal) sind das "Kann meinen Kanal-Stream und meine Beiträge sehen", "Kann mein Standardprofil sehen" und "Kann meine Datei- und Bilderordner sehen". Wer öffentlich Wiki- oder Webseiten anbietet, erlaubt auch das Anschauen dieser durch jeden im Internet.
Den Rest kann man dann ruhigen Gewissens auf "Nur die, denen Du es explizit erlaubst" setzen. Damit können sich die Berechtigungen nur auf die eigenen Verbindungen auswirken.Die passenden Kontaktrollen
Euch muss an dieser Stelle bewusst sein, dass die Standard-Kontaktrolle sehr viele zusätzlich Berechtigungen vergibt:
Diese Kontaktrolle kann man durchaus nutzen, um ein eher "klassisches" Social-Network-Verhalten für bestimmte Verbindungen zu erhalten.
Wenn man aber wirkliche Kontrolle haben möchte, muss man sich für andere Verbindungen weitere Kontaktrollen erstellen."Follower"
Sinnvoll wäre z.B. als neuer Standard für neue Verbindungen die Rolle "Follower". Diese erstellen wir, setzen die Option "Neuen Kontakten automatisch diese Rolle zuweisen" (damit wird die Option aus der Standard-Kontaktrolle gelöscht) und geben keine weiteren Berechtigungen, außer "Darf meine Beiträge kommentieren und mögen/nicht mögen". Damit verfügen Verbindungen mit dieser Kontaktrolle nur die in der Kanalrolle vergebenen Berechtigungen plus die Möglichkeit zum Kommentieren und liken/disliken. Wenn sich jemand mit Eurem Kanal verbindet, dann verhält er sich wie ein reiner Follower. Diese Kontaktrolle ist sinnvoll, wenn Ihr es anderen gestatten möchtet, Euch zu folgen.
Wenn Ihr meint, solche "Follower" sollten auch Eure Verbindungen anschauen können, gewährt Ihr zusätzlich halt auch diese Berechtigung."Followed"
Die nächste sinnvolle Kontaktrolle könnte dann z.B. "Followed" genannt werden. Dieser Rolle räumt Ihr dann, zusätzlich zu den Berechtigungen von "Follower", noch "Kann mir die Beiträge aus seinem Kanal schicken" ein, damit Ihr auch die Beiträge der Verbindung in Eurem Stream sehen könnt. Damit es sich auch "echt" anfühlt, wären hier auch noch die Berechtigungen "Kann mir direkte Nachrichten schicken", "Kann Profile und Profilsachen mögen/nicht mögen" und "Kann mit mir chatten" praktikabel.
Diese Kontaktrolle vergebt Ihr dann, wenn Ihr selbst eine Verbindung zu einem fremden Kanal herstellt... und an Kanäle, die Euch eine Kontaktanfrage schicken und denen Ihr "zurückfolgen" möchtet."Followed+"
Eine Weitere Kontaktrolle würde ich "Followed+" nennen. Die ist für Kontakte aus dem Grid, und von den owa-fähigen Deinsten Forte und Friendica. Diesen kann man die zusätzliche Berechtigung "Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen" erteilen (wenn man denn möchte). Das Wall-to-Wall-Posting ist eine spezielle Art, Postings zu veröffentlichen. Wen eine unserer Verbindung ein Wall-Posting auf unserem Kanal veröffentlicht, dann erscheint dieses Posting in unserem Kanalstream. Es ist also in unserem Kanal veröffentlicht.Mehr
Für gute Freunde, verwandte, Mitglieder eines Teams, Vereins etc. kann man dann, je nach Notwendigkeit noch weitere Berechtigungen vergeben und für jede erdenkliche Art von Verbindungen ganz exakt zugeschnittene Kontaktrollen erstellen.Privacy Gruppen für genauere Steuerung
Privacy Gruppen sind Gruppen von Verbindungen, mit denen man das Teilen von Inhalten steuern kann. Sie ähneln dem, was man bei Google+ als "Kreise" kannte und was bei Diaspora* als "Aspekte" existiert. Möchte man einen Inhalt an eine bestimmte Gruppe von Verbindungen teilen, so kann man diese Verbindungen in eine Gruppe einfügen und mit den Berechtigungs-Einstellungen festlegen, dass der Inhalt ausschließlich mit den Gruppenmitgliedern geteilt wird. Das macht eine geschlossene Gruppenkommunikation möglich.
Eine weitere praktische Anwendung von Privacy Gruppen ist das zuteilen von Kontaktrollen auf einen Rutsch. Wenn man eine Kontaktrolle in der App "Contact Roles" öffnet, kann man auswählen, dass diese Kontaktrolle allen Gruppenmitgliedern einer Privacy Gruppe zugewiesen wird. Beachte: Das wirkt sich nur auf Verbindungen aus, die sich zu diesem Zeitpunkt bereits in der Privacy Gruppe befanden. Auf später hinzugefügte Verbindungen wirkt es sich nicht aus. Hier muss man ggf. die Gruppen-Zuweisung wiederholen.Die Repeat-Hölle verlassen
Es gibt Nutzer im Fediverse, die wirklich exzessiv "Boosten/Repeaten". Trotzdem mag man diesen Nutzern folgen, weil die wenigen (oder vielleicht nicht einmal wenigen) ihrer eigenen Postings insteressant sind und man sie in seinem Stream finden möchte. Aber es kommt zu viel "Rauschen" herein, weil halt auch zu viel wiederholt wird. Bei Hubzilla ist es kein Problem, diese Repeats loszuwerden, ohne die "echten" Postings zu verlieren. Man kann für jede Verbindung einen Filter einrichten, der z.B. Repeats der Verbindung nicht in den Stream importiert.
Dafür öffnet man aus der App "Verbindungen" heraus den Verbindungs-Editor (kleines Bleistift-Symbol) und trägt im Tab "Filter für den Inhalt" im Feld "Beiträge mit diesem Text nicht importieren" die Zeile?verb == Announce
ein. Damit werden Repeats (Wiederholungen / Boosts) von dieser Verbindung nicht mehr in den eigenen Stream importiert.Kanalfilter
Neben den eben erwähnten Kontaktfiltern gibt es auch noch Kanalfilter, die sich auf den gesamten Kanal auswirken. Auch hier könnte man z.B. die Zeile zur Repeat-Unterdrückung unterbringen. Das würde dann aber bewirken, dass gar keine Repeats mehr im Kanal erscheinen, also auch solche nicht, die vielleicht erwünscht sind.
Kanalfilter findet man unter Einstellungen ➔ Kanal-Einstellungen ➔ Beiträge mit diesem Text nicht importierenInhaltswarnung
Während bei den meisten Diensten im Fediverse der Verfasser dafür verantwortlich gemacht wird, bestimmte Inhalte hinter einer Inhaltswarnung zu verstecken, funktioniert Hubzilla genau anders herum. Hier legt der Empfänger fest, was ihn "triggern" könnte oder was ihn "nervt". Das ist eigentlich auch ausgesprochen sinnvoll, weil ich selbst am besten weiß, was ich nicht sofort in meinem Stream sehen möchte. Wenn der Absender dafür verantwortlich ist, muss er ja erahnen, was ich nicht sehen möchte... und verbirgt solche Inhalte dann zwangsweise auch vor anderen Nutzern, die davor aber gar nicht gewarnt werden möchten.
Wer sich mit Hubzilla also vor bestimmten Inhalten schützen möchte, installiert die App "NSFW". Das ist eine einfache Filter-App, in welcher man eingeben kann, bei welchen Inhalten ein Posting zunächst ausgeblendet hinter einer Schaltfläche verborgen bleibt. Es kommt also nicht darauf an, das der Absender errät, was ich nicht sehen möchte und eine Inhaltswarnung verwendet (die sich dann auch auf alle auswirkt, die seinen Beitrag anschauen), sondern darauf, dass ich als Empfänger festlege, was verborgen werden soll.
Bewege ich mich also nur im Grid und habe auch nur Verbindungen zum Grid, muss ich mich um die Befindlichkeiten anderer nicht kümmern. Sobald man aber auch Teil des Fediverse wird, hilft unseren "NSFW"-App nicht weiter, denn die meisten anderen Dienste haben diesen Mechanismus nicht. Möchten wir also rücksichtsvoll vorgehen, müssen wir doch auch für andre mitdenken und erraten, was irgendwen in der weiten Welt "triggern" könnte.
Und das Ausblenden eines solchen Eintrags verwirklichen wir dann einfach, indem wir das Zusammenfassungsfeld (Summary) im Beitragseditor z.B. mit "Inhaltswarnung" befüllen. Nun sind auch nutzer anderer Dienste "geschützt".
Nun aber ein Spezialfall:
Es ist allgemein bekannt, dass viele sich entsetzt schütteln, wenn sie in einem Posting von Dieter Bohlen angestarrt werden (mir selbst geht es nicht so... ich mag ihn... zu erklären weshalb, würde hier aber zu weit führen). Nun wollen wir ein Posting verfassen, in welchem ein Bild von D. B. eingebunden ist. Um Nutzer aus dem Grid zu schützen, müsste ich z.B. das Wort "Bohlen" im Text unterbringen, und schon wären alle "gerettet", die in "NSFW" dieses Wort als Filter haben.
Aber angenommen, wir wollen nur das Bild selbst ausblenden und ahnen, dass es Nutzer gibt, die gerne mit Holz arbeiten und deshalb das Wort "Bohlen" auch nicht als Inhaltswarnung im Filter haben. Nun, dann können wir das Bild bei Hubzilla einfach zwischen die Tags[spoiler][/spoiler]packen. Funktioniert prima! Nur... für Mastodon-Nutzer funktioniert das nicht. Mastodon (und viele andere Fediverse-Dienste) kennen keinen extra Spoiler. Hinzu kommt das bei vielen dieser Dienste Bilder gar nicht in ein Posting eingebunden werden, sondern als Anhang am Posting dranhängen. Selbst wenn sie das Spoiler-Tag kennen würden, würde der Empfänger das Gesicht von D. B. wieder sehen, weil es außerhalb des Postings unten dranhängt.
Aber ehrlich... das soll echt nicht UNSER Problem sein. Wir können alles dafür tun, dass bestimmte Inhalte verborgen bleiben, aber nichts daran ändern, wenn andere Dienste das nicht richtig verarbeiten.
Abgesehen davon ist es möglich auch Teile eines Postings zunächst zu verbergen (BTW: beliebig viele Teile), indem man das Spoiler-Tag verwendet. Funktioniert aber zuverlässig halt nur im Grid.Zeichenbegrenzung
Na ja, was soll man sagen?
Hubzilla packt an die 16 Millionen Zeichen. Dieser Artikel hier ist also ein Fliegenschiss mit ca. 24.000 Zeichen. ;-)Textgestaltung
BBcode "Hubzilla-Flavour" bietet umfangreiche Textgestaltungsmöglichkeiten. Leider werden diese vom derzeitigen Beitragseditor nicht alle vereinfacht z.B. über Buttons und Dialoge angeboten. Hier müsste dringend noch nachgebessert werden (könnte mein nächstes Projekt werden). Zumindest verfügt der Editor über eine Autovervollständigung, die hilfreich ist, wenn man weiß, was die BBcode Tags bewirken.
Was Hubzilla von vielen Diensten unterscheidet ist, dass Medien wirklich in den Beitrag eingebettet werden, also an der Stelle erscheinen, wo wir sie unterbringen. Die Anzahl an Medien ist außerdem ebenfalls nicht beschränkt.
Bedenkt aber, wenn Ihr Beiträge ins Fediverse teilt, dass es Dienste gibt, die nicht nur Medien (also z.B. Bilder) hinten anhängen, sondern auch auf wenige (bei Mastodon vier) begrenzen. Es ist deshalb sinnvoll, einen Hinweis auf die tatsächliche Anzahl von Bildern hinzuweisen und dass es erforderlich sein kann, das Original-Posting auf Eurer Heimat-Instanz zu besuchen, um alle Bilder (und die auch noch korrekt eingebettet) sehen zu können. Klingt komisch, ist aber so. ;-) :-DFazit
Kommt einfach ins Grid! Besorgt euch einen Account bei Hubzilla. Ihr könnt das ja zusätzlich zu Eurem aktuellen Fediverse-Account tun. Und importiert Eure Follower-/Following-Liste. Dafür gibt es (sofern der von Euch gewählte Hub das Addon installiert hat) inzwischen ein Addon, das die typischen Exportdateien (csv) von Mastodon und co. verarbeitet. Richtet Euren Kanal so ein, wie Ihr es euch vorstellt und nutzt es.
Es ist durchaus möglich, dass Ihr dann irgendwann immer öfter mit Hubzilla, statt mit dem ursprünglichen Dienst im Fediverse unterwegs seid. Und wenn Ihr dann auch noch Kontakte zu Nutzern im Grid habt, werdet Ihr feststellen, dass die soziale Interaktion damit noch viel komfortabler ist. Vielleicht wagt ja dann irgendwann auch die eine oder andere eurer alten Verbindungen auch den Schritt und Ihr könnt den Komfort gemeinsam genießen.
Anhänge
Wer?
Was?
#hubzilla #zot #nomad #grid #fediverse -
Kommt doch ins Grid!
👉Permalink
Wehklagen über Spam-Wellen, über unangemessene Postings, über Dauer-Repeater (Extrem-Booster) über mangelnde Berechtigungskontrolle über nicht wirklich funktionierende Inhaltswarnungen sind Teil des Fediverse. Dann auch noch das Beklagen über Zeichenbegrenzungen, unzureichende Formatierungsmöglichkeiten, eingeschränkte Umfragen, Beschränkungen mitgeschickter, oft nicht einbettbarer, sondern nur angehängter Bilder gehören auch dazu.Mein Rat: Kommt doch ins Grid!
Grid? Was ist das denn?
Das Grid ist der Netzwerkverbund aller Dienste, die Zot6/Nomad als Kommunikationsprotokoll verwenden. Aktuell sind das Hubzilla, (streams) und Zap (das zwar nicht wirklich weiterentwickelt wird... es gibt aber aktuell mindestens einen Hub, der mit Zap läuft).
Innerhalb des Grid greifen nicht nur die herausragenden Möglichkeiten des Berechtigungssystems vollständig, sondern der Zugriff auf beschränkte Ressourcen wird auch noch mittels magicAuth extrem komfortabel, weil der Nutzer sich gar nicht darum kümmern muss, seine Berechtigung für den Zugriff einer Ressource nachzuweisen. Läuft automatisch.
Hinzu kommt dann aber auch noch, dass viele der Vorteile des Berechtigungssystems auch auf die Interaktion mit dem ActivityPub-Fediverse wirken, sofern man sich nicht ausschließlich auf das Grid beschränkt.
Bei Hubzilla und (streams) hat man wirklich die Möglichkeit, ganz exakt festzulegen, wie man mit anderen Nutzern im Fediverse (Kanälen) interagiert. Ich gehe hier auf die Verfahrensweise mit Hubzilla ein, die vielleicht zunächst etwas komplizierter erscheint, aber trotzdem, wenn man es verstanden hat, recht einfach ist. Ich beschränke mich deshalb, weil es ausgesprochen unwahrscheinlich ist, dass irgendwer einen (streams)-Hub findet und sich dort registriert. Hubzilla zu nutzen ist in dieser Hinsicht wesentlich einfacher.Vordefinierte Rollen oder eigene Entscheidungen
Um seinen Stream (so nennt sich das, was bei anderen Diensten die "Timeline" heißt) sauber zu halten und Belästigungen zu vermeiden, muss man sich zunächst für eine Kanalrolle entscheiden. Foren lasse ich hier bewusst weg, denn die sind ein Spezialfall. Zur Auswahl stehen lediglich drei Varianten: Öffentlich, Persönlich und Benutzerdefiniert. Öffentlich und Persönlich sind bequem, weil einem damit einiges an Denkarbeit abgenommen wird. Allerdings beschränkt man sich damit auch in den Möglichkeiten.
Bei der Kanalrolle "Öffentlich" ist es Verbindungen (also diejenigen, die einem selbst folgen und denen man ebenfalls folg, aber auch jedem im Internet) grundsätzlich erlaubt, unsere öffentlichen Postings zu sehen (in ihrem Stream/ihrer Timeline), unser Standardprofil, unsere Verbindungen, unsere öffentlichen Dateien (Bilder, Dokumente etc.) und unsere Web- und Wikiseiten zu sehen. Außerdem dürfen Verbindungen unsere Beiträge kommentieren, liken/disliken, uns Direktnachrichten schicken, Inhalte unseres Profils liken/disliken und mit uns chatten.
Diese Rechte können wir den Verbindungen (außer wir schränken bestimmte einzelne Inhalte im Zugriff explizit ein) auch nicht verwehren.
Es fällt auf, dass wir selbst es mit diesen Berechtigungen unseren Verbindungen nicht erlauben, uns Postings zu schicken. Wir sehen damit also in unserem Stream nicht, was die Verbindung selbst öffentlich gepostet hat. Damit wäre die Verbindung also nur sowas wie ein "Follower" (wie man es von anderen Diensten kennt). Es muss also noch eine weitere Möglichkeit geben, unseren Verbindungen dieses zu erlauben, damit wir mit unserem Kanal auch ein "richtiges" Social-Network-Erlebnis haben.
Die Berechtigungen, die ich eben beschrieben habe, sind die Berechtigungen der Kanalrollen. Sie beziehen sich also auf unserem Kanal. Es gibt aber auch noch die Kontaktrolle, welche unsere Verbindungen betrifft. In dieser können zusätzliche Berechtigungen eingeräumt werden (aber keine Berechtigungen der Kanalrolle wieder entzogen werden).
Zu jeder Kanalrolle gibt es immer eine Standard-Kontaktrolle. Bei der Kanalrolle "Öffentlich" erlaubt diese Standard-Kontaktrolle unseren Verbindungen, uns ihre Beiträge in unseren Stream zu schicken. Die werden damit also auch "followed". Zusätzlich erteilt die Standard-Kontaktrolle unseren Verbindungen auch noch das Wall-to-Wall-Posting und das Spiegeln unserer Beiträge in einem anderen Kanal. Auf diese beiden Spezialfälle gehe ich jetzt hier nicht ein. Wir ignorieren sie einfach erstmal.
Ein Kanal mit der Kanalrolle "Öffentlich" verhält sich also genau so, wie man das von ganz normalen Social-Network-Accounts erwartet.
Hinweis: Alles, was wir mit einem solchen Kanal veröffentlichen, wird auch öffentlich geteilt, sofern wir dies nicht für eine einzelne Ressource explizit anders festlegen.
Bei der Kanalrolle "Persönlich" ist es grundsätzlich erlaubt, unsere öffentlichen Postings (als "Follower") und unser Standard-Profil zu sehen. Ebenso unsere öffentlich geteilten Dateien, Webseiten und Wikis. Mehr nicht!
Auch "Persönlich" hat eine spezielle Standard-Kontaktrolle. Diese erlaubt es Verbindungen zusätzlich , uns Beiträge in unseren Stream zu schicken ("Followed") und unsere Verbindungen zu sehen.
Beachte: Alles, was wir mit einem solchen Kanal veröffentlichen ist nicht öffentlich, also nur für unsere Verbindungen zu sehen, sofern wir die Ressource nicht explizit als "öffentlich" veröffentlichen. Das ist ein entscheidender Unterschied zur Kanalrolle "Öffentlich".
Das Verhalten, dass bei der Kanalrolle "Persönlich" grundsätzlich erstmal nur an Verbindungen und damit nicht-öffentlich geteilt wird, liegt nicht an der Kanalrolle und auch nicht an der Standrad-Kontaktrolle, sondern am Mechanismus der Privacy Gruppen.
Auch wenn die App "Privacy Gruppen" nicht installiert ist, verfügt jeder Kanal über eine Privacy Gruppe namens "Freunde". Alle neuen Verbindungen werden dieser Privacy Gruppe automatisch zugewiesen. Bei der Kanalrolle "Öffentlich" hat das keine direkten Auswirkungen. Sehr wohl aber bei der Kanalrolle "Persönlich". Hier ist die Privacy Gruppe "Freunde" nämlich so konfiguriert, dass alles, was wir teilen grundsätzlich nur an Mitglieder dieser Gruppe geteilt wird. Das bewirkt, dass wir nicht-öffentlich teilen, es sei denn, wir stellen das für eine einzelne Ressource explizit ein.
Die dritte Kanalrolle, "Benutzerdefiniert" ist die flexibelste und auch diejenige, die man auswählen sollte, wenn man wirklich alle Unzulänglichkeiten unterbinden möchte, die andere Fediverse-Dienste aufweisen.
"Benutzerdefiniert" bedeutet, dass man auch die Kanalrolle in allen Berechtigungen selbst einstellen kann. In der Grundeinstellung, also wenn man einen Kanal mit dieser Rolle frisch erstellt hat, entspricht die Kanalrolle des Rolle "Persönlich", erlaubt aber grundsätzlich auch, dass Dritte unsere Verbindungen sehen können. Die Standard-Verbindungsrolle entspricht 1:1 der Verbindungsrolle "Persönlich". Die Privacy-Gruppe "Freunde" ist hingegen wieder so eingestellt, dass grundsätzlich öffentlich geteilt wird.Eigene Entscheidungen
Wer nun also von seinem Social-Network-Dienst mehr möchte, als 08/15, muss Entscheidungen treffen, also ein wenig Hirnschmalz investieren. Ohne das geht es nicht... weder bei Hubzilla, noch bei irgendeinem anderen System, denn dieses weiß ja nicht, kann ja nicht ahnen, was wir möchten. Das müssen wir schon selbst wissen oder uns klarmachen. Wer das nicht will, muss halt mit den vordefinierten Rollen leben, die auch schon vieles besser machen, als bei manchem anderen System und die -- aufgrund der vorhandenen Mechanismen -- durchaus gewisse Dinge unterbinden können.
Möchte man aber kein System "von der Stange", sind einige Vorüberlegungen und Einstellungen notwendig.
Zunächst einmal hier die einzelnen Berechtigungen, die Hubzilla zur Konfiguration anbietet:- Kann meinen Kanal-Stream und meine Beiträge sehen
- Kann mir die Beiträge aus seinem Kanal schicken
- Kann mein Standardprofil sehen
- Kann meine Verbindungen sehen
- Kann meine Datei- und Bilderordner sehen
- Kann in meine Datei- und Bilderordner hochladen/ändern
- Kann die Webseiten meines Kanals sehen
- Kann meine Wiki-Seiten sehen
- Kann Webseiten in meinem Kanal erstellen/ändern
- Kann meine Wiki-Seiten bearbeiten
- Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen
- Darf meine Beiträge kommentieren und mögen/nicht mögen
- Kann mir direkte Nachrichten schicken
- Kann Profile und Profilsachen mögen/nicht mögen
- Kann mit mir chatten
- Kann meine öffentlichen Beiträge in anderen Kanälen zitieren/spiegeln
- Kann meinen Kanal administrieren
Etliche dieser Berechtigungen erklären sich von selbst, einige sind vielleicht nicht so klar und einige wenige kann man falsch verstehen. Im Anhang gibt es eine Tabelle, in der genauer erklärt wird, was sich hinter den Berechtigungen verbirgt.
Diese Berechtigungen sind das WAS, also was andere mit Inhalten/Ressourcen unseres Kanals tun können.
Dazu gehört dann aber auch noch das WER! Damit legen wir fest, wem bestimmte Dinge erlaubt bzw. verboten sind:- Jeder im Internet
- Jeder authentifizierte
- Alle Hubzilla-Mitglieder
- Jeder auf dieser Webseite
- Beliebige Verbindungen
- Angenommene Verbindungen
- Nur die, denen Du es explizit erlaubst
- Nur ich
Auch hier gibt es einige "Wers", die etwas näher erläutert werden müssen. Dafür gibt es ebenfalls eine kleine Tabelle im Anhang.
Die Wichtigsten Adressaten für Berechtigungen sind: "Jeder im Internet" und "Nur die, denen Du es explizit erlaubst".
Nun ist es an der Zeit, sich Gedanken darüber zu machen, was man wem denn nun erlauben möchte. Dafür arbeitet man einfach die einzelnen Berechtigungen hintereinander ab und legt die Berechtigten fest.
Im Hauptmenü (das Menü, welches sich hinter unserem Avatarbild versteckt) wählt man
Einstellungen ➔ Kanal-Einstellungen
und legt im Abschnitt Grundeinstellungen die gewünschte Kanalrolle (Channel Role) fest. Also für unsere Zwecke "Benutzerdefiniert".
Nun wechselt man zu Einstellungen ➔ Privacy-Einstellungen
Die Grundeinstallungen dort sind selbsterklärend und sollten nach den eigenen Wünschen festgelegt werden. Wichtig ist hier die einzige "nicht selbsterklärende" Einstellung "Enable OCAP access". Dies ermöglicht, dass Medien (Bilder etc.) auch dann in einem Thread angezeigt werden, wenn diese eigentlich im Zugriff eingeschränkt sind. Wird diese Option nicht gewählt, kann es vorkommen, dass man eingebettete Bilder in manchen Threads nicht sieht. Meine Empfehlung: Option einschalten!
Die eigentliche Einstellung der Berechtigungen, die unser Kanal einräumt, findet man unter dem Button "Benutzerdefinierte Konfiguration der Channel Role" (dies wird bei den Kanalrollen "Öffentlich" und "Persönlich" nicht angezeigt, weil man diese dort nicht ändern kann).
Es wird eine Warnung angezeigt, die zwar berechtigt ist, aber wir WISSEN ja, was wir tun wollen.Die sorgfältig konfigurierte Kanalrolle
Deshalb klicken wir auf den Button "Risiko akzeptieren und weitermachen" und landen im Formular für die genannten Berechtigungen. Die können wir nun nach unseren Wünschen und nachdem wir uns Gedanken gemacht haben, entsprechend konfigurieren.
Dabei aber immer daran denken: Die Berechtigung, die wir hier erteilen, können wir generell nicht zurücknehmen. Wir können sie höchstens in Einzelfällen "übersteuern", indem wir Inhalte/Ressourcen über die Berechtigungs-Einstellungen bestimmten Verbindungen zugänglich machen.
Es ist also ausgesprochen sinnvoll, bei der Kanalrolle so wenig freizügige Berechtigungen zu vergeben, wie möglich und nur so viele, wie für den Zweck absolut nötig.
Bedenkt: Nur was Ihr für "Jeder im Internet" erlaubt, kann auch wirklich öffentlich gesehen werden. Die spezielleren Berechtigungen sind eher etwas für Spezialfälle. "Nur die, denen Du es explizit erlaubst" wirkt sich hingegen ausschließlich auf Verbindungen aus.
Bedeutet: Alles, was wirklich jeder im Internet sehen können soll, bekommt "Jeder im Internet" (bei einem typischen öffentlichen Social-Network-Kanal) sind das "Kann meinen Kanal-Stream und meine Beiträge sehen", "Kann mein Standardprofil sehen" und "Kann meine Datei- und Bilderordner sehen". Wer öffentlich Wiki- oder Webseiten anbietet, erlaubt auch das Anschauen dieser durch jeden im Internet.
Den Rest kann man dann ruhigen Gewissens auf "Nur die, denen Du es explizit erlaubst" setzen. Damit können sich die Berechtigungen nur auf die eigenen Verbindungen auswirken.Die passenden Kontaktrollen
Euch muss an dieser Stelle bewusst sein, dass die Standard-Kontaktrolle sehr viele zusätzlich Berechtigungen vergibt:
Diese Kontaktrolle kann man durchaus nutzen, um ein eher "klassisches" Social-Network-Verhalten für bestimmte Verbindungen zu erhalten.
Wenn man aber wirkliche Kontrolle haben möchte, muss man sich für andere Verbindungen weitere Kontaktrollen erstellen."Follower"
Sinnvoll wäre z.B. als neuer Standard für neue Verbindungen die Rolle "Follower". Diese erstellen wir, setzen die Option "Neuen Kontakten automatisch diese Rolle zuweisen" (damit wird die Option aus der Standard-Kontaktrolle gelöscht) und geben keine weiteren Berechtigungen, außer "Darf meine Beiträge kommentieren und mögen/nicht mögen". Damit verfügen Verbindungen mit dieser Kontaktrolle nur die in der Kanalrolle vergebenen Berechtigungen plus die Möglichkeit zum Kommentieren und liken/disliken. Wenn sich jemand mit Eurem Kanal verbindet, dann verhält er sich wie ein reiner Follower. Diese Kontaktrolle ist sinnvoll, wenn Ihr es anderen gestatten möchtet, Euch zu folgen.
Wenn Ihr meint, solche "Follower" sollten auch Eure Verbindungen anschauen können, gewährt Ihr zusätzlich halt auch diese Berechtigung."Followed"
Die nächste sinnvolle Kontaktrolle könnte dann z.B. "Followed" genannt werden. Dieser Rolle räumt Ihr dann, zusätzlich zu den Berechtigungen von "Follower", noch "Kann mir die Beiträge aus seinem Kanal schicken" ein, damit Ihr auch die Beiträge der Verbindung in Eurem Stream sehen könnt. Damit es sich auch "echt" anfühlt, wären hier auch noch die Berechtigungen "Kann mir direkte Nachrichten schicken", "Kann Profile und Profilsachen mögen/nicht mögen" und "Kann mit mir chatten" praktikabel.
Diese Kontaktrolle vergebt Ihr dann, wenn Ihr selbst eine Verbindung zu einem fremden Kanal herstellt... und an Kanäle, die Euch eine Kontaktanfrage schicken und denen Ihr "zurückfolgen" möchtet."Followed+"
Eine Weitere Kontaktrolle würde ich "Followed+" nennen. Die ist für Kontakte aus dem Grid, und von den owa-fähigen Deinsten Forte und Friendica. Diesen kann man die zusätzliche Berechtigung "Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen" erteilen (wenn man denn möchte). Das Wall-to-Wall-Posting ist eine spezielle Art, Postings zu veröffentlichen. Wen eine unserer Verbindung ein Wall-Posting auf unserem Kanal veröffentlicht, dann erscheint dieses Posting in unserem Kanalstream. Es ist also in unserem Kanal veröffentlicht.Mehr
Für gute Freunde, verwandte, Mitglieder eines Teams, Vereins etc. kann man dann, je nach Notwendigkeit noch weitere Berechtigungen vergeben und für jede erdenkliche Art von Verbindungen ganz exakt zugeschnittene Kontaktrollen erstellen.Privacy Gruppen für genauere Steuerung
Privacy Gruppen sind Gruppen von Verbindungen, mit denen man das Teilen von Inhalten steuern kann. Sie ähneln dem, was man bei Google+ als "Kreise" kannte und was bei Diaspora* als "Aspekte" existiert. Möchte man einen Inhalt an eine bestimmte Gruppe von Verbindungen teilen, so kann man diese Verbindungen in eine Gruppe einfügen und mit den Berechtigungs-Einstellungen festlegen, dass der Inhalt ausschließlich mit den Gruppenmitgliedern geteilt wird. Das macht eine geschlossene Gruppenkommunikation möglich.
Eine weitere praktische Anwendung von Privacy Gruppen ist das zuteilen von Kontaktrollen auf einen Rutsch. Wenn man eine Kontaktrolle in der App "Contact Roles" öffnet, kann man auswählen, dass diese Kontaktrolle allen Gruppenmitgliedern einer Privacy Gruppe zugewiesen wird. Beachte: Das wirkt sich nur auf Verbindungen aus, die sich zu diesem Zeitpunkt bereits in der Privacy Gruppe befanden. Auf später hinzugefügte Verbindungen wirkt es sich nicht aus. Hier muss man ggf. die Gruppen-Zuweisung wiederholen.Die Repeat-Hölle verlassen
Es gibt Nutzer im Fediverse, die wirklich exzessiv "Boosten/Repeaten". Trotzdem mag man diesen Nutzern folgen, weil die wenigen (oder vielleicht nicht einmal wenigen) ihrer eigenen Postings insteressant sind und man sie in seinem Stream finden möchte. Aber es kommt zu viel "Rauschen" herein, weil halt auch zu viel wiederholt wird. Bei Hubzilla ist es kein Problem, diese Repeats loszuwerden, ohne die "echten" Postings zu verlieren. Man kann für jede Verbindung einen Filter einrichten, der z.B. Repeats der Verbindung nicht in den Stream importiert.
Dafür öffnet man aus der App "Verbindungen" heraus den Verbindungs-Editor (kleines Bleistift-Symbol) und trägt im Tab "Filter für den Inhalt" im Feld "Beiträge mit diesem Text nicht importieren" die Zeile?verb == Announce
ein. Damit werden Repeats (Wiederholungen / Boosts) von dieser Verbindung nicht mehr in den eigenen Stream importiert.Kanalfilter
Neben den eben erwähnten Kontaktfiltern gibt es auch noch Kanalfilter, die sich auf den gesamten Kanal auswirken. Auch hier könnte man z.B. die Zeile zur Repeat-Unterdrückung unterbringen. Das würde dann aber bewirken, dass gar keine Repeats mehr im Kanal erscheinen, also auch solche nicht, die vielleicht erwünscht sind.
Kanalfilter findet man unter Einstellungen ➔ Kanal-Einstellungen ➔ Beiträge mit diesem Text nicht importierenInhaltswarnung
Während bei den meisten Diensten im Fediverse der Verfasser dafür verantwortlich gemacht wird, bestimmte Inhalte hinter einer Inhaltswarnung zu verstecken, funktioniert Hubzilla genau anders herum. Hier legt der Empfänger fest, was ihn "triggern" könnte oder was ihn "nervt". Das ist eigentlich auch ausgesprochen sinnvoll, weil ich selbst am besten weiß, was ich nicht sofort in meinem Stream sehen möchte. Wenn der Absender dafür verantwortlich ist, muss er ja erahnen, was ich nicht sehen möchte... und verbirgt solche Inhalte dann zwangsweise auch vor anderen Nutzern, die davor aber gar nicht gewarnt werden möchten.
Wer sich mit Hubzilla also vor bestimmten Inhalten schützen möchte, installiert die App "NSFW". Das ist eine einfache Filter-App, in welcher man eingeben kann, bei welchen Inhalten ein Posting zunächst ausgeblendet hinter einer Schaltfläche verborgen bleibt. Es kommt also nicht darauf an, das der Absender errät, was ich nicht sehen möchte und eine Inhaltswarnung verwendet (die sich dann auch auf alle auswirkt, die seinen Beitrag anschauen), sondern darauf, dass ich als Empfänger festlege, was verborgen werden soll.
Bewege ich mich also nur im Grid und habe auch nur Verbindungen zum Grid, muss ich mich um die Befindlichkeiten anderer nicht kümmern. Sobald man aber auch Teil des Fediverse wird, hilft unseren "NSFW"-App nicht weiter, denn die meisten anderen Dienste haben diesen Mechanismus nicht. Möchten wir also rücksichtsvoll vorgehen, müssen wir doch auch für andre mitdenken und erraten, was irgendwen in der weiten Welt "triggern" könnte.
Und das Ausblenden eines solchen Eintrags verwirklichen wir dann einfach, indem wir das Zusammenfassungsfeld (Summary) im Beitragseditor z.B. mit "Inhaltswarnung" befüllen. Nun sind auch nutzer anderer Dienste "geschützt".
Nun aber ein Spezialfall:
Es ist allgemein bekannt, dass viele sich entsetzt schütteln, wenn sie in einem Posting von Dieter Bohlen angestarrt werden (mir selbst geht es nicht so... ich mag ihn... zu erklären weshalb, würde hier aber zu weit führen). Nun wollen wir ein Posting verfassen, in welchem ein Bild von D. B. eingebunden ist. Um Nutzer aus dem Grid zu schützen, müsste ich z.B. das Wort "Bohlen" im Text unterbringen, und schon wären alle "gerettet", die in "NSFW" dieses Wort als Filter haben.
Aber angenommen, wir wollen nur das Bild selbst ausblenden und ahnen, dass es Nutzer gibt, die gerne mit Holz arbeiten und deshalb das Wort "Bohlen" auch nicht als Inhaltswarnung im Filter haben. Nun, dann können wir das Bild bei Hubzilla einfach zwischen die Tags[spoiler][/spoiler]packen. Funktioniert prima! Nur... für Mastodon-Nutzer funktioniert das nicht. Mastodon (und viele andere Fediverse-Dienste) kennen keinen extra Spoiler. Hinzu kommt das bei vielen dieser Dienste Bilder gar nicht in ein Posting eingebunden werden, sondern als Anhang am Posting dranhängen. Selbst wenn sie das Spoiler-Tag kennen würden, würde der Empfänger das Gesicht von D. B. wieder sehen, weil es außerhalb des Postings unten dranhängt.
Aber ehrlich... das soll echt nicht UNSER Problem sein. Wir können alles dafür tun, dass bestimmte Inhalte verborgen bleiben, aber nichts daran ändern, wenn andere Dienste das nicht richtig verarbeiten.
Abgesehen davon ist es möglich auch Teile eines Postings zunächst zu verbergen (BTW: beliebig viele Teile), indem man das Spoiler-Tag verwendet. Funktioniert aber zuverlässig halt nur im Grid.Zeichenbegrenzung
Na ja, was soll man sagen?
Hubzilla packt an die 16 Millionen Zeichen. Dieser Artikel hier ist also ein Fliegenschiss mit ca. 24.000 Zeichen. ;-)Textgestaltung
BBcode "Hubzilla-Flavour" bietet umfangreiche Textgestaltungsmöglichkeiten. Leider werden diese vom derzeitigen Beitragseditor nicht alle vereinfacht z.B. über Buttons und Dialoge angeboten. Hier müsste dringend noch nachgebessert werden (könnte mein nächstes Projekt werden). Zumindest verfügt der Editor über eine Autovervollständigung, die hilfreich ist, wenn man weiß, was die BBcode Tags bewirken.
Was Hubzilla von vielen Diensten unterscheidet ist, dass Medien wirklich in den Beitrag eingebettet werden, also an der Stelle erscheinen, wo wir sie unterbringen. Die Anzahl an Medien ist außerdem ebenfalls nicht beschränkt.
Bedenkt aber, wenn Ihr Beiträge ins Fediverse teilt, dass es Dienste gibt, die nicht nur Medien (also z.B. Bilder) hinten anhängen, sondern auch auf wenige (bei Mastodon vier) begrenzen. Es ist deshalb sinnvoll, einen Hinweis auf die tatsächliche Anzahl von Bildern hinzuweisen und dass es erforderlich sein kann, das Original-Posting auf Eurer Heimat-Instanz zu besuchen, um alle Bilder (und die auch noch korrekt eingebettet) sehen zu können. Klingt komisch, ist aber so. ;-) :-DFazit
Kommt einfach ins Grid! Besorgt euch einen Account bei Hubzilla. Ihr könnt das ja zusätzlich zu Eurem aktuellen Fediverse-Account tun. Und importiert Eure Follower-/Following-Liste. Dafür gibt es (sofern der von Euch gewählte Hub das Addon installiert hat) inzwischen ein Addon, das die typischen Exportdateien (csv) von Mastodon und co. verarbeitet. Richtet Euren Kanal so ein, wie Ihr es euch vorstellt und nutzt es.
Es ist durchaus möglich, dass Ihr dann irgendwann immer öfter mit Hubzilla, statt mit dem ursprünglichen Dienst im Fediverse unterwegs seid. Und wenn Ihr dann auch noch Kontakte zu Nutzern im Grid habt, werdet Ihr feststellen, dass die soziale Interaktion damit noch viel komfortabler ist. Vielleicht wagt ja dann irgendwann auch die eine oder andere eurer alten Verbindungen auch den Schritt und Ihr könnt den Komfort gemeinsam genießen.
Anhänge
Wer?
Was?
#hubzilla #zot #nomad #grid #fediverse -
Kommt doch ins Grid!
👉Permalink
Wehklagen über Spam-Wellen, über unangemessene Postings, über Dauer-Repeater (Extrem-Booster) über mangelnde Berechtigungskontrolle über nicht wirklich funktionierende Inhaltswarnungen sind Teil des Fediverse. Dann auch noch das Beklagen über Zeichenbegrenzungen, unzureichende Formatierungsmöglichkeiten, eingeschränkte Umfragen, Beschränkungen mitgeschickter, oft nicht einbettbarer, sondern nur angehängter Bilder gehören auch dazu.Mein Rat: Kommt doch ins Grid!
Grid? Was ist das denn?
Das Grid ist der Netzwerkverbund aller Dienste, die Zot6/Nomad als Kommunikationsprotokoll verwenden. Aktuell sind das Hubzilla, (streams) und Zap (das zwar nicht wirklich weiterentwickelt wird... es gibt aber aktuell mindestens einen Hub, der mit Zap läuft).
Innerhalb des Grid greifen nicht nur die herausragenden Möglichkeiten des Berechtigungssystems vollständig, sondern der Zugriff auf beschränkte Ressourcen wird auch noch mittels magicAuth extrem komfortabel, weil der Nutzer sich gar nicht darum kümmern muss, seine Berechtigung für den Zugriff einer Ressource nachzuweisen. Läuft automatisch.
Hinzu kommt dann aber auch noch, dass viele der Vorteile des Berechtigungssystems auch auf die Interaktion mit dem ActivityPub-Fediverse wirken, sofern man sich nicht ausschließlich auf das Grid beschränkt.
Bei Hubzilla und (streams) hat man wirklich die Möglichkeit, ganz exakt festzulegen, wie man mit anderen Nutzern im Fediverse (Kanälen) interagiert. Ich gehe hier auf die Verfahrensweise mit Hubzilla ein, die vielleicht zunächst etwas komplizierter erscheint, aber trotzdem, wenn man es verstanden hat, recht einfach ist. Ich beschränke mich deshalb, weil es ausgesprochen unwahrscheinlich ist, dass irgendwer einen (streams)-Hub findet und sich dort registriert. Hubzilla zu nutzen ist in dieser Hinsicht wesentlich einfacher.Vordefinierte Rollen oder eigene Entscheidungen
Um seinen Stream (so nennt sich das, was bei anderen Diensten die "Timeline" heißt) sauber zu halten und Belästigungen zu vermeiden, muss man sich zunächst für eine Kanalrolle entscheiden. Foren lasse ich hier bewusst weg, denn die sind ein Spezialfall. Zur Auswahl stehen lediglich drei Varianten: Öffentlich, Persönlich und Benutzerdefiniert. Öffentlich und Persönlich sind bequem, weil einem damit einiges an Denkarbeit abgenommen wird. Allerdings beschränkt man sich damit auch in den Möglichkeiten.
Bei der Kanalrolle "Öffentlich" ist es Verbindungen (also diejenigen, die einem selbst folgen und denen man ebenfalls folg, aber auch jedem im Internet) grundsätzlich erlaubt, unsere öffentlichen Postings zu sehen (in ihrem Stream/ihrer Timeline), unser Standardprofil, unsere Verbindungen, unsere öffentlichen Dateien (Bilder, Dokumente etc.) und unsere Web- und Wikiseiten zu sehen. Außerdem dürfen Verbindungen unsere Beiträge kommentieren, liken/disliken, uns Direktnachrichten schicken, Inhalte unseres Profils liken/disliken und mit uns chatten.
Diese Rechte können wir den Verbindungen (außer wir schränken bestimmte einzelne Inhalte im Zugriff explizit ein) auch nicht verwehren.
Es fällt auf, dass wir selbst es mit diesen Berechtigungen unseren Verbindungen nicht erlauben, uns Postings zu schicken. Wir sehen damit also in unserem Stream nicht, was die Verbindung selbst öffentlich gepostet hat. Damit wäre die Verbindung also nur sowas wie ein "Follower" (wie man es von anderen Diensten kennt). Es muss also noch eine weitere Möglichkeit geben, unseren Verbindungen dieses zu erlauben, damit wir mit unserem Kanal auch ein "richtiges" Social-Network-Erlebnis haben.
Die Berechtigungen, die ich eben beschrieben habe, sind die Berechtigungen der Kanalrollen. Sie beziehen sich also auf unserem Kanal. Es gibt aber auch noch die Kontaktrolle, welche unsere Verbindungen betrifft. In dieser können zusätzliche Berechtigungen eingeräumt werden (aber keine Berechtigungen der Kanalrolle wieder entzogen werden).
Zu jeder Kanalrolle gibt es immer eine Standard-Kontaktrolle. Bei der Kanalrolle "Öffentlich" erlaubt diese Standard-Kontaktrolle unseren Verbindungen, uns ihre Beiträge in unseren Stream zu schicken. Die werden damit also auch "followed". Zusätzlich erteilt die Standard-Kontaktrolle unseren Verbindungen auch noch das Wall-to-Wall-Posting und das Spiegeln unserer Beiträge in einem anderen Kanal. Auf diese beiden Spezialfälle gehe ich jetzt hier nicht ein. Wir ignorieren sie einfach erstmal.
Ein Kanal mit der Kanalrolle "Öffentlich" verhält sich also genau so, wie man das von ganz normalen Social-Network-Accounts erwartet.
Hinweis: Alles, was wir mit einem solchen Kanal veröffentlichen, wird auch öffentlich geteilt, sofern wir dies nicht für eine einzelne Ressource explizit anders festlegen.
Bei der Kanalrolle "Persönlich" ist es grundsätzlich erlaubt, unsere öffentlichen Postings (als "Follower") und unser Standard-Profil zu sehen. Ebenso unsere öffentlich geteilten Dateien, Webseiten und Wikis. Mehr nicht!
Auch "Persönlich" hat eine spezielle Standard-Kontaktrolle. Diese erlaubt es Verbindungen zusätzlich , uns Beiträge in unseren Stream zu schicken ("Followed") und unsere Verbindungen zu sehen.
Beachte: Alles, was wir mit einem solchen Kanal veröffentlichen ist nicht öffentlich, also nur für unsere Verbindungen zu sehen, sofern wir die Ressource nicht explizit als "öffentlich" veröffentlichen. Das ist ein entscheidender Unterschied zur Kanalrolle "Öffentlich".
Das Verhalten, dass bei der Kanalrolle "Persönlich" grundsätzlich erstmal nur an Verbindungen und damit nicht-öffentlich geteilt wird, liegt nicht an der Kanalrolle und auch nicht an der Standrad-Kontaktrolle, sondern am Mechanismus der Privacy Gruppen.
Auch wenn die App "Privacy Gruppen" nicht installiert ist, verfügt jeder Kanal über eine Privacy Gruppe namens "Freunde". Alle neuen Verbindungen werden dieser Privacy Gruppe automatisch zugewiesen. Bei der Kanalrolle "Öffentlich" hat das keine direkten Auswirkungen. Sehr wohl aber bei der Kanalrolle "Persönlich". Hier ist die Privacy Gruppe "Freunde" nämlich so konfiguriert, dass alles, was wir teilen grundsätzlich nur an Mitglieder dieser Gruppe geteilt wird. Das bewirkt, dass wir nicht-öffentlich teilen, es sei denn, wir stellen das für eine einzelne Ressource explizit ein.
Die dritte Kanalrolle, "Benutzerdefiniert" ist die flexibelste und auch diejenige, die man auswählen sollte, wenn man wirklich alle Unzulänglichkeiten unterbinden möchte, die andere Fediverse-Dienste aufweisen.
"Benutzerdefiniert" bedeutet, dass man auch die Kanalrolle in allen Berechtigungen selbst einstellen kann. In der Grundeinstellung, also wenn man einen Kanal mit dieser Rolle frisch erstellt hat, entspricht die Kanalrolle des Rolle "Persönlich", erlaubt aber grundsätzlich auch, dass Dritte unsere Verbindungen sehen können. Die Standard-Verbindungsrolle entspricht 1:1 der Verbindungsrolle "Persönlich". Die Privacy-Gruppe "Freunde" ist hingegen wieder so eingestellt, dass grundsätzlich öffentlich geteilt wird.Eigene Entscheidungen
Wer nun also von seinem Social-Network-Dienst mehr möchte, als 08/15, muss Entscheidungen treffen, also ein wenig Hirnschmalz investieren. Ohne das geht es nicht... weder bei Hubzilla, noch bei irgendeinem anderen System, denn dieses weiß ja nicht, kann ja nicht ahnen, was wir möchten. Das müssen wir schon selbst wissen oder uns klarmachen. Wer das nicht will, muss halt mit den vordefinierten Rollen leben, die auch schon vieles besser machen, als bei manchem anderen System und die -- aufgrund der vorhandenen Mechanismen -- durchaus gewisse Dinge unterbinden können.
Möchte man aber kein System "von der Stange", sind einige Vorüberlegungen und Einstellungen notwendig.
Zunächst einmal hier die einzelnen Berechtigungen, die Hubzilla zur Konfiguration anbietet:- Kann meinen Kanal-Stream und meine Beiträge sehen
- Kann mir die Beiträge aus seinem Kanal schicken
- Kann mein Standardprofil sehen
- Kann meine Verbindungen sehen
- Kann meine Datei- und Bilderordner sehen
- Kann in meine Datei- und Bilderordner hochladen/ändern
- Kann die Webseiten meines Kanals sehen
- Kann meine Wiki-Seiten sehen
- Kann Webseiten in meinem Kanal erstellen/ändern
- Kann meine Wiki-Seiten bearbeiten
- Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen
- Darf meine Beiträge kommentieren und mögen/nicht mögen
- Kann mir direkte Nachrichten schicken
- Kann Profile und Profilsachen mögen/nicht mögen
- Kann mit mir chatten
- Kann meine öffentlichen Beiträge in anderen Kanälen zitieren/spiegeln
- Kann meinen Kanal administrieren
Etliche dieser Berechtigungen erklären sich von selbst, einige sind vielleicht nicht so klar und einige wenige kann man falsch verstehen. Im Anhang gibt es eine Tabelle, in der genauer erklärt wird, was sich hinter den Berechtigungen verbirgt.
Diese Berechtigungen sind das WAS, also was andere mit Inhalten/Ressourcen unseres Kanals tun können.
Dazu gehört dann aber auch noch das WER! Damit legen wir fest, wem bestimmte Dinge erlaubt bzw. verboten sind:- Jeder im Internet
- Jeder authentifizierte
- Alle Hubzilla-Mitglieder
- Jeder auf dieser Webseite
- Beliebige Verbindungen
- Angenommene Verbindungen
- Nur die, denen Du es explizit erlaubst
- Nur ich
Auch hier gibt es einige "Wers", die etwas näher erläutert werden müssen. Dafür gibt es ebenfalls eine kleine Tabelle im Anhang.
Die Wichtigsten Adressaten für Berechtigungen sind: "Jeder im Internet" und "Nur die, denen Du es explizit erlaubst".
Nun ist es an der Zeit, sich Gedanken darüber zu machen, was man wem denn nun erlauben möchte. Dafür arbeitet man einfach die einzelnen Berechtigungen hintereinander ab und legt die Berechtigten fest.
Im Hauptmenü (das Menü, welches sich hinter unserem Avatarbild versteckt) wählt man
Einstellungen ➔ Kanal-Einstellungen
und legt im Abschnitt Grundeinstellungen die gewünschte Kanalrolle (Channel Role) fest. Also für unsere Zwecke "Benutzerdefiniert".
Nun wechselt man zu Einstellungen ➔ Privacy-Einstellungen
Die Grundeinstallungen dort sind selbsterklärend und sollten nach den eigenen Wünschen festgelegt werden. Wichtig ist hier die einzige "nicht selbsterklärende" Einstellung "Enable OCAP access". Dies ermöglicht, dass Medien (Bilder etc.) auch dann in einem Thread angezeigt werden, wenn diese eigentlich im Zugriff eingeschränkt sind. Wird diese Option nicht gewählt, kann es vorkommen, dass man eingebettete Bilder in manchen Threads nicht sieht. Meine Empfehlung: Option einschalten!
Die eigentliche Einstellung der Berechtigungen, die unser Kanal einräumt, findet man unter dem Button "Benutzerdefinierte Konfiguration der Channel Role" (dies wird bei den Kanalrollen "Öffentlich" und "Persönlich" nicht angezeigt, weil man diese dort nicht ändern kann).
Es wird eine Warnung angezeigt, die zwar berechtigt ist, aber wir WISSEN ja, was wir tun wollen.Die sorgfältig konfigurierte Kanalrolle
Deshalb klicken wir auf den Button "Risiko akzeptieren und weitermachen" und landen im Formular für die genannten Berechtigungen. Die können wir nun nach unseren Wünschen und nachdem wir uns Gedanken gemacht haben, entsprechend konfigurieren.
Dabei aber immer daran denken: Die Berechtigung, die wir hier erteilen, können wir generell nicht zurücknehmen. Wir können sie höchstens in Einzelfällen "übersteuern", indem wir Inhalte/Ressourcen über die Berechtigungs-Einstellungen bestimmten Verbindungen zugänglich machen.
Es ist also ausgesprochen sinnvoll, bei der Kanalrolle so wenig freizügige Berechtigungen zu vergeben, wie möglich und nur so viele, wie für den Zweck absolut nötig.
Bedenkt: Nur was Ihr für "Jeder im Internet" erlaubt, kann auch wirklich öffentlich gesehen werden. Die spezielleren Berechtigungen sind eher etwas für Spezialfälle. "Nur die, denen Du es explizit erlaubst" wirkt sich hingegen ausschließlich auf Verbindungen aus.
Bedeutet: Alles, was wirklich jeder im Internet sehen können soll, bekommt "Jeder im Internet" (bei einem typischen öffentlichen Social-Network-Kanal) sind das "Kann meinen Kanal-Stream und meine Beiträge sehen", "Kann mein Standardprofil sehen" und "Kann meine Datei- und Bilderordner sehen". Wer öffentlich Wiki- oder Webseiten anbietet, erlaubt auch das Anschauen dieser durch jeden im Internet.
Den Rest kann man dann ruhigen Gewissens auf "Nur die, denen Du es explizit erlaubst" setzen. Damit können sich die Berechtigungen nur auf die eigenen Verbindungen auswirken.Die passenden Kontaktrollen
Euch muss an dieser Stelle bewusst sein, dass die Standard-Kontaktrolle sehr viele zusätzlich Berechtigungen vergibt:
Diese Kontaktrolle kann man durchaus nutzen, um ein eher "klassisches" Social-Network-Verhalten für bestimmte Verbindungen zu erhalten.
Wenn man aber wirkliche Kontrolle haben möchte, muss man sich für andere Verbindungen weitere Kontaktrollen erstellen."Follower"
Sinnvoll wäre z.B. als neuer Standard für neue Verbindungen die Rolle "Follower". Diese erstellen wir, setzen die Option "Neuen Kontakten automatisch diese Rolle zuweisen" (damit wird die Option aus der Standard-Kontaktrolle gelöscht) und geben keine weiteren Berechtigungen, außer "Darf meine Beiträge kommentieren und mögen/nicht mögen". Damit verfügen Verbindungen mit dieser Kontaktrolle nur die in der Kanalrolle vergebenen Berechtigungen plus die Möglichkeit zum Kommentieren und liken/disliken. Wenn sich jemand mit Eurem Kanal verbindet, dann verhält er sich wie ein reiner Follower. Diese Kontaktrolle ist sinnvoll, wenn Ihr es anderen gestatten möchtet, Euch zu folgen.
Wenn Ihr meint, solche "Follower" sollten auch Eure Verbindungen anschauen können, gewährt Ihr zusätzlich halt auch diese Berechtigung."Followed"
Die nächste sinnvolle Kontaktrolle könnte dann z.B. "Followed" genannt werden. Dieser Rolle räumt Ihr dann, zusätzlich zu den Berechtigungen von "Follower", noch "Kann mir die Beiträge aus seinem Kanal schicken" ein, damit Ihr auch die Beiträge der Verbindung in Eurem Stream sehen könnt. Damit es sich auch "echt" anfühlt, wären hier auch noch die Berechtigungen "Kann mir direkte Nachrichten schicken", "Kann Profile und Profilsachen mögen/nicht mögen" und "Kann mit mir chatten" praktikabel.
Diese Kontaktrolle vergebt Ihr dann, wenn Ihr selbst eine Verbindung zu einem fremden Kanal herstellt... und an Kanäle, die Euch eine Kontaktanfrage schicken und denen Ihr "zurückfolgen" möchtet."Followed+"
Eine Weitere Kontaktrolle würde ich "Followed+" nennen. Die ist für Kontakte aus dem Grid, und von den owa-fähigen Deinsten Forte und Friendica. Diesen kann man die zusätzliche Berechtigung "Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen" erteilen (wenn man denn möchte). Das Wall-to-Wall-Posting ist eine spezielle Art, Postings zu veröffentlichen. Wen eine unserer Verbindung ein Wall-Posting auf unserem Kanal veröffentlicht, dann erscheint dieses Posting in unserem Kanalstream. Es ist also in unserem Kanal veröffentlicht.Mehr
Für gute Freunde, verwandte, Mitglieder eines Teams, Vereins etc. kann man dann, je nach Notwendigkeit noch weitere Berechtigungen vergeben und für jede erdenkliche Art von Verbindungen ganz exakt zugeschnittene Kontaktrollen erstellen.Privacy Gruppen für genauere Steuerung
Privacy Gruppen sind Gruppen von Verbindungen, mit denen man das Teilen von Inhalten steuern kann. Sie ähneln dem, was man bei Google+ als "Kreise" kannte und was bei Diaspora* als "Aspekte" existiert. Möchte man einen Inhalt an eine bestimmte Gruppe von Verbindungen teilen, so kann man diese Verbindungen in eine Gruppe einfügen und mit den Berechtigungs-Einstellungen festlegen, dass der Inhalt ausschließlich mit den Gruppenmitgliedern geteilt wird. Das macht eine geschlossene Gruppenkommunikation möglich.
Eine weitere praktische Anwendung von Privacy Gruppen ist das zuteilen von Kontaktrollen auf einen Rutsch. Wenn man eine Kontaktrolle in der App "Contact Roles" öffnet, kann man auswählen, dass diese Kontaktrolle allen Gruppenmitgliedern einer Privacy Gruppe zugewiesen wird. Beachte: Das wirkt sich nur auf Verbindungen aus, die sich zu diesem Zeitpunkt bereits in der Privacy Gruppe befanden. Auf später hinzugefügte Verbindungen wirkt es sich nicht aus. Hier muss man ggf. die Gruppen-Zuweisung wiederholen.Die Repeat-Hölle verlassen
Es gibt Nutzer im Fediverse, die wirklich exzessiv "Boosten/Repeaten". Trotzdem mag man diesen Nutzern folgen, weil die wenigen (oder vielleicht nicht einmal wenigen) ihrer eigenen Postings insteressant sind und man sie in seinem Stream finden möchte. Aber es kommt zu viel "Rauschen" herein, weil halt auch zu viel wiederholt wird. Bei Hubzilla ist es kein Problem, diese Repeats loszuwerden, ohne die "echten" Postings zu verlieren. Man kann für jede Verbindung einen Filter einrichten, der z.B. Repeats der Verbindung nicht in den Stream importiert.
Dafür öffnet man aus der App "Verbindungen" heraus den Verbindungs-Editor (kleines Bleistift-Symbol) und trägt im Tab "Filter für den Inhalt" im Feld "Beiträge mit diesem Text nicht importieren" die Zeile?verb == Announce
ein. Damit werden Repeats (Wiederholungen / Boosts) von dieser Verbindung nicht mehr in den eigenen Stream importiert.Kanalfilter
Neben den eben erwähnten Kontaktfiltern gibt es auch noch Kanalfilter, die sich auf den gesamten Kanal auswirken. Auch hier könnte man z.B. die Zeile zur Repeat-Unterdrückung unterbringen. Das würde dann aber bewirken, dass gar keine Repeats mehr im Kanal erscheinen, also auch solche nicht, die vielleicht erwünscht sind.
Kanalfilter findet man unter Einstellungen ➔ Kanal-Einstellungen ➔ Beiträge mit diesem Text nicht importierenInhaltswarnung
Während bei den meisten Diensten im Fediverse der Verfasser dafür verantwortlich gemacht wird, bestimmte Inhalte hinter einer Inhaltswarnung zu verstecken, funktioniert Hubzilla genau anders herum. Hier legt der Empfänger fest, was ihn "triggern" könnte oder was ihn "nervt". Das ist eigentlich auch ausgesprochen sinnvoll, weil ich selbst am besten weiß, was ich nicht sofort in meinem Stream sehen möchte. Wenn der Absender dafür verantwortlich ist, muss er ja erahnen, was ich nicht sehen möchte... und verbirgt solche Inhalte dann zwangsweise auch vor anderen Nutzern, die davor aber gar nicht gewarnt werden möchten.
Wer sich mit Hubzilla also vor bestimmten Inhalten schützen möchte, installiert die App "NSFW". Das ist eine einfache Filter-App, in welcher man eingeben kann, bei welchen Inhalten ein Posting zunächst ausgeblendet hinter einer Schaltfläche verborgen bleibt. Es kommt also nicht darauf an, das der Absender errät, was ich nicht sehen möchte und eine Inhaltswarnung verwendet (die sich dann auch auf alle auswirkt, die seinen Beitrag anschauen), sondern darauf, dass ich als Empfänger festlege, was verborgen werden soll.
Bewege ich mich also nur im Grid und habe auch nur Verbindungen zum Grid, muss ich mich um die Befindlichkeiten anderer nicht kümmern. Sobald man aber auch Teil des Fediverse wird, hilft unseren "NSFW"-App nicht weiter, denn die meisten anderen Dienste haben diesen Mechanismus nicht. Möchten wir also rücksichtsvoll vorgehen, müssen wir doch auch für andre mitdenken und erraten, was irgendwen in der weiten Welt "triggern" könnte.
Und das Ausblenden eines solchen Eintrags verwirklichen wir dann einfach, indem wir das Zusammenfassungsfeld (Summary) im Beitragseditor z.B. mit "Inhaltswarnung" befüllen. Nun sind auch nutzer anderer Dienste "geschützt".
Nun aber ein Spezialfall:
Es ist allgemein bekannt, dass viele sich entsetzt schütteln, wenn sie in einem Posting von Dieter Bohlen angestarrt werden (mir selbst geht es nicht so... ich mag ihn... zu erklären weshalb, würde hier aber zu weit führen). Nun wollen wir ein Posting verfassen, in welchem ein Bild von D. B. eingebunden ist. Um Nutzer aus dem Grid zu schützen, müsste ich z.B. das Wort "Bohlen" im Text unterbringen, und schon wären alle "gerettet", die in "NSFW" dieses Wort als Filter haben.
Aber angenommen, wir wollen nur das Bild selbst ausblenden und ahnen, dass es Nutzer gibt, die gerne mit Holz arbeiten und deshalb das Wort "Bohlen" auch nicht als Inhaltswarnung im Filter haben. Nun, dann können wir das Bild bei Hubzilla einfach zwischen die Tags[spoiler][/spoiler]packen. Funktioniert prima! Nur... für Mastodon-Nutzer funktioniert das nicht. Mastodon (und viele andere Fediverse-Dienste) kennen keinen extra Spoiler. Hinzu kommt das bei vielen dieser Dienste Bilder gar nicht in ein Posting eingebunden werden, sondern als Anhang am Posting dranhängen. Selbst wenn sie das Spoiler-Tag kennen würden, würde der Empfänger das Gesicht von D. B. wieder sehen, weil es außerhalb des Postings unten dranhängt.
Aber ehrlich... das soll echt nicht UNSER Problem sein. Wir können alles dafür tun, dass bestimmte Inhalte verborgen bleiben, aber nichts daran ändern, wenn andere Dienste das nicht richtig verarbeiten.
Abgesehen davon ist es möglich auch Teile eines Postings zunächst zu verbergen (BTW: beliebig viele Teile), indem man das Spoiler-Tag verwendet. Funktioniert aber zuverlässig halt nur im Grid.Zeichenbegrenzung
Na ja, was soll man sagen?
Hubzilla packt an die 16 Millionen Zeichen. Dieser Artikel hier ist also ein Fliegenschiss mit ca. 24.000 Zeichen. ;-)Textgestaltung
BBcode "Hubzilla-Flavour" bietet umfangreiche Textgestaltungsmöglichkeiten. Leider werden diese vom derzeitigen Beitragseditor nicht alle vereinfacht z.B. über Buttons und Dialoge angeboten. Hier müsste dringend noch nachgebessert werden (könnte mein nächstes Projekt werden). Zumindest verfügt der Editor über eine Autovervollständigung, die hilfreich ist, wenn man weiß, was die BBcode Tags bewirken.
Was Hubzilla von vielen Diensten unterscheidet ist, dass Medien wirklich in den Beitrag eingebettet werden, also an der Stelle erscheinen, wo wir sie unterbringen. Die Anzahl an Medien ist außerdem ebenfalls nicht beschränkt.
Bedenkt aber, wenn Ihr Beiträge ins Fediverse teilt, dass es Dienste gibt, die nicht nur Medien (also z.B. Bilder) hinten anhängen, sondern auch auf wenige (bei Mastodon vier) begrenzen. Es ist deshalb sinnvoll, einen Hinweis auf die tatsächliche Anzahl von Bildern hinzuweisen und dass es erforderlich sein kann, das Original-Posting auf Eurer Heimat-Instanz zu besuchen, um alle Bilder (und die auch noch korrekt eingebettet) sehen zu können. Klingt komisch, ist aber so. ;-) :-DFazit
Kommt einfach ins Grid! Besorgt euch einen Account bei Hubzilla. Ihr könnt das ja zusätzlich zu Eurem aktuellen Fediverse-Account tun. Und importiert Eure Follower-/Following-Liste. Dafür gibt es (sofern der von Euch gewählte Hub das Addon installiert hat) inzwischen ein Addon, das die typischen Exportdateien (csv) von Mastodon und co. verarbeitet. Richtet Euren Kanal so ein, wie Ihr es euch vorstellt und nutzt es.
Es ist durchaus möglich, dass Ihr dann irgendwann immer öfter mit Hubzilla, statt mit dem ursprünglichen Dienst im Fediverse unterwegs seid. Und wenn Ihr dann auch noch Kontakte zu Nutzern im Grid habt, werdet Ihr feststellen, dass die soziale Interaktion damit noch viel komfortabler ist. Vielleicht wagt ja dann irgendwann auch die eine oder andere eurer alten Verbindungen auch den Schritt und Ihr könnt den Komfort gemeinsam genießen.
Anhänge
Wer?
Was?
#hubzilla #zot #nomad #grid #fediverse -
Kommt doch ins Grid!
👉Permalink
Wehklagen über Spam-Wellen, über unangemessene Postings, über Dauer-Repeater (Extrem-Booster) über mangelnde Berechtigungskontrolle über nicht wirklich funktionierende Inhaltswarnungen sind Teil des Fediverse. Dann auch noch das Beklagen über Zeichenbegrenzungen, unzureichende Formatierungsmöglichkeiten, eingeschränkte Umfragen, Beschränkungen mitgeschickter, oft nicht einbettbarer, sondern nur angehängter Bilder gehören auch dazu.Mein Rat: Kommt doch ins Grid!
Grid? Was ist das denn?
Das Grid ist der Netzwerkverbund aller Dienste, die Zot6/Nomad als Kommunikationsprotokoll verwenden. Aktuell sind das Hubzilla, (streams) und Zap (das zwar nicht wirklich weiterentwickelt wird... es gibt aber aktuell mindestens einen Hub, der mit Zap läuft).
Innerhalb des Grid greifen nicht nur die herausragenden Möglichkeiten des Berechtigungssystems vollständig, sondern der Zugriff auf beschränkte Ressourcen wird auch noch mittels magicAuth extrem komfortabel, weil der Nutzer sich gar nicht darum kümmern muss, seine Berechtigung für den Zugriff einer Ressource nachzuweisen. Läuft automatisch.
Hinzu kommt dann aber auch noch, dass viele der Vorteile des Berechtigungssystems auch auf die Interaktion mit dem ActivityPub-Fediverse wirken, sofern man sich nicht ausschließlich auf das Grid beschränkt.
Bei Hubzilla und (streams) hat man wirklich die Möglichkeit, ganz exakt festzulegen, wie man mit anderen Nutzern im Fediverse (Kanälen) interagiert. Ich gehe hier auf die Verfahrensweise mit Hubzilla ein, die vielleicht zunächst etwas komplizierter erscheint, aber trotzdem, wenn man es verstanden hat, recht einfach ist. Ich beschränke mich deshalb, weil es ausgesprochen unwahrscheinlich ist, dass irgendwer einen (streams)-Hub findet und sich dort registriert. Hubzilla zu nutzen ist in dieser Hinsicht wesentlich einfacher.Vordefinierte Rollen oder eigene Entscheidungen
Um seinen Stream (so nennt sich das, was bei anderen Diensten die "Timeline" heißt) sauber zu halten und Belästigungen zu vermeiden, muss man sich zunächst für eine Kanalrolle entscheiden. Foren lasse ich hier bewusst weg, denn die sind ein Spezialfall. Zur Auswahl stehen lediglich drei Varianten: Öffentlich, Persönlich und Benutzerdefiniert. Öffentlich und Persönlich sind bequem, weil einem damit einiges an Denkarbeit abgenommen wird. Allerdings beschränkt man sich damit auch in den Möglichkeiten.
Bei der Kanalrolle "Öffentlich" ist es Verbindungen (also diejenigen, die einem selbst folgen und denen man ebenfalls folg, aber auch jedem im Internet) grundsätzlich erlaubt, unsere öffentlichen Postings zu sehen (in ihrem Stream/ihrer Timeline), unser Standardprofil, unsere Verbindungen, unsere öffentlichen Dateien (Bilder, Dokumente etc.) und unsere Web- und Wikiseiten zu sehen. Außerdem dürfen Verbindungen unsere Beiträge kommentieren, liken/disliken, uns Direktnachrichten schicken, Inhalte unseres Profils liken/disliken und mit uns chatten.
Diese Rechte können wir den Verbindungen (außer wir schränken bestimmte einzelne Inhalte im Zugriff explizit ein) auch nicht verwehren.
Es fällt auf, dass wir selbst es mit diesen Berechtigungen unseren Verbindungen nicht erlauben, uns Postings zu schicken. Wir sehen damit also in unserem Stream nicht, was die Verbindung selbst öffentlich gepostet hat. Damit wäre die Verbindung also nur sowas wie ein "Follower" (wie man es von anderen Diensten kennt). Es muss also noch eine weitere Möglichkeit geben, unseren Verbindungen dieses zu erlauben, damit wir mit unserem Kanal auch ein "richtiges" Social-Network-Erlebnis haben.
Die Berechtigungen, die ich eben beschrieben habe, sind die Berechtigungen der Kanalrollen. Sie beziehen sich also auf unserem Kanal. Es gibt aber auch noch die Kontaktrolle, welche unsere Verbindungen betrifft. In dieser können zusätzliche Berechtigungen eingeräumt werden (aber keine Berechtigungen der Kanalrolle wieder entzogen werden).
Zu jeder Kanalrolle gibt es immer eine Standard-Kontaktrolle. Bei der Kanalrolle "Öffentlich" erlaubt diese Standard-Kontaktrolle unseren Verbindungen, uns ihre Beiträge in unseren Stream zu schicken. Die werden damit also auch "followed". Zusätzlich erteilt die Standard-Kontaktrolle unseren Verbindungen auch noch das Wall-to-Wall-Posting und das Spiegeln unserer Beiträge in einem anderen Kanal. Auf diese beiden Spezialfälle gehe ich jetzt hier nicht ein. Wir ignorieren sie einfach erstmal.
Ein Kanal mit der Kanalrolle "Öffentlich" verhält sich also genau so, wie man das von ganz normalen Social-Network-Accounts erwartet.
Hinweis: Alles, was wir mit einem solchen Kanal veröffentlichen, wird auch öffentlich geteilt, sofern wir dies nicht für eine einzelne Ressource explizit anders festlegen.
Bei der Kanalrolle "Persönlich" ist es grundsätzlich erlaubt, unsere öffentlichen Postings (als "Follower") und unser Standard-Profil zu sehen. Ebenso unsere öffentlich geteilten Dateien, Webseiten und Wikis. Mehr nicht!
Auch "Persönlich" hat eine spezielle Standard-Kontaktrolle. Diese erlaubt es Verbindungen zusätzlich , uns Beiträge in unseren Stream zu schicken ("Followed") und unsere Verbindungen zu sehen.
Beachte: Alles, was wir mit einem solchen Kanal veröffentlichen ist nicht öffentlich, also nur für unsere Verbindungen zu sehen, sofern wir die Ressource nicht explizit als "öffentlich" veröffentlichen. Das ist ein entscheidender Unterschied zur Kanalrolle "Öffentlich".
Das Verhalten, dass bei der Kanalrolle "Persönlich" grundsätzlich erstmal nur an Verbindungen und damit nicht-öffentlich geteilt wird, liegt nicht an der Kanalrolle und auch nicht an der Standrad-Kontaktrolle, sondern am Mechanismus der Privacy Gruppen.
Auch wenn die App "Privacy Gruppen" nicht installiert ist, verfügt jeder Kanal über eine Privacy Gruppe namens "Freunde". Alle neuen Verbindungen werden dieser Privacy Gruppe automatisch zugewiesen. Bei der Kanalrolle "Öffentlich" hat das keine direkten Auswirkungen. Sehr wohl aber bei der Kanalrolle "Persönlich". Hier ist die Privacy Gruppe "Freunde" nämlich so konfiguriert, dass alles, was wir teilen grundsätzlich nur an Mitglieder dieser Gruppe geteilt wird. Das bewirkt, dass wir nicht-öffentlich teilen, es sei denn, wir stellen das für eine einzelne Ressource explizit ein.
Die dritte Kanalrolle, "Benutzerdefiniert" ist die flexibelste und auch diejenige, die man auswählen sollte, wenn man wirklich alle Unzulänglichkeiten unterbinden möchte, die andere Fediverse-Dienste aufweisen.
"Benutzerdefiniert" bedeutet, dass man auch die Kanalrolle in allen Berechtigungen selbst einstellen kann. In der Grundeinstellung, also wenn man einen Kanal mit dieser Rolle frisch erstellt hat, entspricht die Kanalrolle des Rolle "Persönlich", erlaubt aber grundsätzlich auch, dass Dritte unsere Verbindungen sehen können. Die Standard-Verbindungsrolle entspricht 1:1 der Verbindungsrolle "Persönlich". Die Privacy-Gruppe "Freunde" ist hingegen wieder so eingestellt, dass grundsätzlich öffentlich geteilt wird.Eigene Entscheidungen
Wer nun also von seinem Social-Network-Dienst mehr möchte, als 08/15, muss Entscheidungen treffen, also ein wenig Hirnschmalz investieren. Ohne das geht es nicht... weder bei Hubzilla, noch bei irgendeinem anderen System, denn dieses weiß ja nicht, kann ja nicht ahnen, was wir möchten. Das müssen wir schon selbst wissen oder uns klarmachen. Wer das nicht will, muss halt mit den vordefinierten Rollen leben, die auch schon vieles besser machen, als bei manchem anderen System und die -- aufgrund der vorhandenen Mechanismen -- durchaus gewisse Dinge unterbinden können.
Möchte man aber kein System "von der Stange", sind einige Vorüberlegungen und Einstellungen notwendig.
Zunächst einmal hier die einzelnen Berechtigungen, die Hubzilla zur Konfiguration anbietet:- Kann meinen Kanal-Stream und meine Beiträge sehen
- Kann mir die Beiträge aus seinem Kanal schicken
- Kann mein Standardprofil sehen
- Kann meine Verbindungen sehen
- Kann meine Datei- und Bilderordner sehen
- Kann in meine Datei- und Bilderordner hochladen/ändern
- Kann die Webseiten meines Kanals sehen
- Kann meine Wiki-Seiten sehen
- Kann Webseiten in meinem Kanal erstellen/ändern
- Kann meine Wiki-Seiten bearbeiten
- Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen
- Darf meine Beiträge kommentieren und mögen/nicht mögen
- Kann mir direkte Nachrichten schicken
- Kann Profile und Profilsachen mögen/nicht mögen
- Kann mit mir chatten
- Kann meine öffentlichen Beiträge in anderen Kanälen zitieren/spiegeln
- Kann meinen Kanal administrieren
Etliche dieser Berechtigungen erklären sich von selbst, einige sind vielleicht nicht so klar und einige wenige kann man falsch verstehen. Im Anhang gibt es eine Tabelle, in der genauer erklärt wird, was sich hinter den Berechtigungen verbirgt.
Diese Berechtigungen sind das WAS, also was andere mit Inhalten/Ressourcen unseres Kanals tun können.
Dazu gehört dann aber auch noch das WER! Damit legen wir fest, wem bestimmte Dinge erlaubt bzw. verboten sind:- Jeder im Internet
- Jeder authentifizierte
- Alle Hubzilla-Mitglieder
- Jeder auf dieser Webseite
- Beliebige Verbindungen
- Angenommene Verbindungen
- Nur die, denen Du es explizit erlaubst
- Nur ich
Auch hier gibt es einige "Wers", die etwas näher erläutert werden müssen. Dafür gibt es ebenfalls eine kleine Tabelle im Anhang.
Die Wichtigsten Adressaten für Berechtigungen sind: "Jeder im Internet" und "Nur die, denen Du es explizit erlaubst".
Nun ist es an der Zeit, sich Gedanken darüber zu machen, was man wem denn nun erlauben möchte. Dafür arbeitet man einfach die einzelnen Berechtigungen hintereinander ab und legt die Berechtigten fest.
Im Hauptmenü (das Menü, welches sich hinter unserem Avatarbild versteckt) wählt man
Einstellungen ➔ Kanal-Einstellungen
und legt im Abschnitt Grundeinstellungen die gewünschte Kanalrolle (Channel Role) fest. Also für unsere Zwecke "Benutzerdefiniert".
Nun wechselt man zu Einstellungen ➔ Privacy-Einstellungen
Die Grundeinstallungen dort sind selbsterklärend und sollten nach den eigenen Wünschen festgelegt werden. Wichtig ist hier die einzige "nicht selbsterklärende" Einstellung "Enable OCAP access". Dies ermöglicht, dass Medien (Bilder etc.) auch dann in einem Thread angezeigt werden, wenn diese eigentlich im Zugriff eingeschränkt sind. Wird diese Option nicht gewählt, kann es vorkommen, dass man eingebettete Bilder in manchen Threads nicht sieht. Meine Empfehlung: Option einschalten!
Die eigentliche Einstellung der Berechtigungen, die unser Kanal einräumt, findet man unter dem Button "Benutzerdefinierte Konfiguration der Channel Role" (dies wird bei den Kanalrollen "Öffentlich" und "Persönlich" nicht angezeigt, weil man diese dort nicht ändern kann).
Es wird eine Warnung angezeigt, die zwar berechtigt ist, aber wir WISSEN ja, was wir tun wollen.Die sorgfältig konfigurierte Kanalrolle
Deshalb klicken wir auf den Button "Risiko akzeptieren und weitermachen" und landen im Formular für die genannten Berechtigungen. Die können wir nun nach unseren Wünschen und nachdem wir uns Gedanken gemacht haben, entsprechend konfigurieren.
Dabei aber immer daran denken: Die Berechtigung, die wir hier erteilen, können wir generell nicht zurücknehmen. Wir können sie höchstens in Einzelfällen "übersteuern", indem wir Inhalte/Ressourcen über die Berechtigungs-Einstellungen bestimmten Verbindungen zugänglich machen.
Es ist also ausgesprochen sinnvoll, bei der Kanalrolle so wenig freizügige Berechtigungen zu vergeben, wie möglich und nur so viele, wie für den Zweck absolut nötig.
Bedenkt: Nur was Ihr für "Jeder im Internet" erlaubt, kann auch wirklich öffentlich gesehen werden. Die spezielleren Berechtigungen sind eher etwas für Spezialfälle. "Nur die, denen Du es explizit erlaubst" wirkt sich hingegen ausschließlich auf Verbindungen aus.
Bedeutet: Alles, was wirklich jeder im Internet sehen können soll, bekommt "Jeder im Internet" (bei einem typischen öffentlichen Social-Network-Kanal) sind das "Kann meinen Kanal-Stream und meine Beiträge sehen", "Kann mein Standardprofil sehen" und "Kann meine Datei- und Bilderordner sehen". Wer öffentlich Wiki- oder Webseiten anbietet, erlaubt auch das Anschauen dieser durch jeden im Internet.
Den Rest kann man dann ruhigen Gewissens auf "Nur die, denen Du es explizit erlaubst" setzen. Damit können sich die Berechtigungen nur auf die eigenen Verbindungen auswirken.Die passenden Kontaktrollen
Euch muss an dieser Stelle bewusst sein, dass die Standard-Kontaktrolle sehr viele zusätzlich Berechtigungen vergibt:
Diese Kontaktrolle kann man durchaus nutzen, um ein eher "klassisches" Social-Network-Verhalten für bestimmte Verbindungen zu erhalten.
Wenn man aber wirkliche Kontrolle haben möchte, muss man sich für andere Verbindungen weitere Kontaktrollen erstellen."Follower"
Sinnvoll wäre z.B. als neuer Standard für neue Verbindungen die Rolle "Follower". Diese erstellen wir, setzen die Option "Neuen Kontakten automatisch diese Rolle zuweisen" (damit wird die Option aus der Standard-Kontaktrolle gelöscht) und geben keine weiteren Berechtigungen, außer "Darf meine Beiträge kommentieren und mögen/nicht mögen". Damit verfügen Verbindungen mit dieser Kontaktrolle nur die in der Kanalrolle vergebenen Berechtigungen plus die Möglichkeit zum Kommentieren und liken/disliken. Wenn sich jemand mit Eurem Kanal verbindet, dann verhält er sich wie ein reiner Follower. Diese Kontaktrolle ist sinnvoll, wenn Ihr es anderen gestatten möchtet, Euch zu folgen.
Wenn Ihr meint, solche "Follower" sollten auch Eure Verbindungen anschauen können, gewährt Ihr zusätzlich halt auch diese Berechtigung."Followed"
Die nächste sinnvolle Kontaktrolle könnte dann z.B. "Followed" genannt werden. Dieser Rolle räumt Ihr dann, zusätzlich zu den Berechtigungen von "Follower", noch "Kann mir die Beiträge aus seinem Kanal schicken" ein, damit Ihr auch die Beiträge der Verbindung in Eurem Stream sehen könnt. Damit es sich auch "echt" anfühlt, wären hier auch noch die Berechtigungen "Kann mir direkte Nachrichten schicken", "Kann Profile und Profilsachen mögen/nicht mögen" und "Kann mit mir chatten" praktikabel.
Diese Kontaktrolle vergebt Ihr dann, wenn Ihr selbst eine Verbindung zu einem fremden Kanal herstellt... und an Kanäle, die Euch eine Kontaktanfrage schicken und denen Ihr "zurückfolgen" möchtet."Followed+"
Eine Weitere Kontaktrolle würde ich "Followed+" nennen. Die ist für Kontakte aus dem Grid, und von den owa-fähigen Deinsten Forte und Friendica. Diesen kann man die zusätzliche Berechtigung "Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen" erteilen (wenn man denn möchte). Das Wall-to-Wall-Posting ist eine spezielle Art, Postings zu veröffentlichen. Wen eine unserer Verbindung ein Wall-Posting auf unserem Kanal veröffentlicht, dann erscheint dieses Posting in unserem Kanalstream. Es ist also in unserem Kanal veröffentlicht.Mehr
Für gute Freunde, verwandte, Mitglieder eines Teams, Vereins etc. kann man dann, je nach Notwendigkeit noch weitere Berechtigungen vergeben und für jede erdenkliche Art von Verbindungen ganz exakt zugeschnittene Kontaktrollen erstellen.Privacy Gruppen für genauere Steuerung
Privacy Gruppen sind Gruppen von Verbindungen, mit denen man das Teilen von Inhalten steuern kann. Sie ähneln dem, was man bei Google+ als "Kreise" kannte und was bei Diaspora* als "Aspekte" existiert. Möchte man einen Inhalt an eine bestimmte Gruppe von Verbindungen teilen, so kann man diese Verbindungen in eine Gruppe einfügen und mit den Berechtigungs-Einstellungen festlegen, dass der Inhalt ausschließlich mit den Gruppenmitgliedern geteilt wird. Das macht eine geschlossene Gruppenkommunikation möglich.
Eine weitere praktische Anwendung von Privacy Gruppen ist das zuteilen von Kontaktrollen auf einen Rutsch. Wenn man eine Kontaktrolle in der App "Contact Roles" öffnet, kann man auswählen, dass diese Kontaktrolle allen Gruppenmitgliedern einer Privacy Gruppe zugewiesen wird. Beachte: Das wirkt sich nur auf Verbindungen aus, die sich zu diesem Zeitpunkt bereits in der Privacy Gruppe befanden. Auf später hinzugefügte Verbindungen wirkt es sich nicht aus. Hier muss man ggf. die Gruppen-Zuweisung wiederholen.Die Repeat-Hölle verlassen
Es gibt Nutzer im Fediverse, die wirklich exzessiv "Boosten/Repeaten". Trotzdem mag man diesen Nutzern folgen, weil die wenigen (oder vielleicht nicht einmal wenigen) ihrer eigenen Postings insteressant sind und man sie in seinem Stream finden möchte. Aber es kommt zu viel "Rauschen" herein, weil halt auch zu viel wiederholt wird. Bei Hubzilla ist es kein Problem, diese Repeats loszuwerden, ohne die "echten" Postings zu verlieren. Man kann für jede Verbindung einen Filter einrichten, der z.B. Repeats der Verbindung nicht in den Stream importiert.
Dafür öffnet man aus der App "Verbindungen" heraus den Verbindungs-Editor (kleines Bleistift-Symbol) und trägt im Tab "Filter für den Inhalt" im Feld "Beiträge mit diesem Text nicht importieren" die Zeile?verb == Announce
ein. Damit werden Repeats (Wiederholungen / Boosts) von dieser Verbindung nicht mehr in den eigenen Stream importiert.Kanalfilter
Neben den eben erwähnten Kontaktfiltern gibt es auch noch Kanalfilter, die sich auf den gesamten Kanal auswirken. Auch hier könnte man z.B. die Zeile zur Repeat-Unterdrückung unterbringen. Das würde dann aber bewirken, dass gar keine Repeats mehr im Kanal erscheinen, also auch solche nicht, die vielleicht erwünscht sind.
Kanalfilter findet man unter Einstellungen ➔ Kanal-Einstellungen ➔ Beiträge mit diesem Text nicht importierenInhaltswarnung
Während bei den meisten Diensten im Fediverse der Verfasser dafür verantwortlich gemacht wird, bestimmte Inhalte hinter einer Inhaltswarnung zu verstecken, funktioniert Hubzilla genau anders herum. Hier legt der Empfänger fest, was ihn "triggern" könnte oder was ihn "nervt". Das ist eigentlich auch ausgesprochen sinnvoll, weil ich selbst am besten weiß, was ich nicht sofort in meinem Stream sehen möchte. Wenn der Absender dafür verantwortlich ist, muss er ja erahnen, was ich nicht sehen möchte... und verbirgt solche Inhalte dann zwangsweise auch vor anderen Nutzern, die davor aber gar nicht gewarnt werden möchten.
Wer sich mit Hubzilla also vor bestimmten Inhalten schützen möchte, installiert die App "NSFW". Das ist eine einfache Filter-App, in welcher man eingeben kann, bei welchen Inhalten ein Posting zunächst ausgeblendet hinter einer Schaltfläche verborgen bleibt. Es kommt also nicht darauf an, das der Absender errät, was ich nicht sehen möchte und eine Inhaltswarnung verwendet (die sich dann auch auf alle auswirkt, die seinen Beitrag anschauen), sondern darauf, dass ich als Empfänger festlege, was verborgen werden soll.
Bewege ich mich also nur im Grid und habe auch nur Verbindungen zum Grid, muss ich mich um die Befindlichkeiten anderer nicht kümmern. Sobald man aber auch Teil des Fediverse wird, hilft unseren "NSFW"-App nicht weiter, denn die meisten anderen Dienste haben diesen Mechanismus nicht. Möchten wir also rücksichtsvoll vorgehen, müssen wir doch auch für andre mitdenken und erraten, was irgendwen in der weiten Welt "triggern" könnte.
Und das Ausblenden eines solchen Eintrags verwirklichen wir dann einfach, indem wir das Zusammenfassungsfeld (Summary) im Beitragseditor z.B. mit "Inhaltswarnung" befüllen. Nun sind auch nutzer anderer Dienste "geschützt".
Nun aber ein Spezialfall:
Es ist allgemein bekannt, dass viele sich entsetzt schütteln, wenn sie in einem Posting von Dieter Bohlen angestarrt werden (mir selbst geht es nicht so... ich mag ihn... zu erklären weshalb, würde hier aber zu weit führen). Nun wollen wir ein Posting verfassen, in welchem ein Bild von D. B. eingebunden ist. Um Nutzer aus dem Grid zu schützen, müsste ich z.B. das Wort "Bohlen" im Text unterbringen, und schon wären alle "gerettet", die in "NSFW" dieses Wort als Filter haben.
Aber angenommen, wir wollen nur das Bild selbst ausblenden und ahnen, dass es Nutzer gibt, die gerne mit Holz arbeiten und deshalb das Wort "Bohlen" auch nicht als Inhaltswarnung im Filter haben. Nun, dann können wir das Bild bei Hubzilla einfach zwischen die Tags[spoiler][/spoiler]packen. Funktioniert prima! Nur... für Mastodon-Nutzer funktioniert das nicht. Mastodon (und viele andere Fediverse-Dienste) kennen keinen extra Spoiler. Hinzu kommt das bei vielen dieser Dienste Bilder gar nicht in ein Posting eingebunden werden, sondern als Anhang am Posting dranhängen. Selbst wenn sie das Spoiler-Tag kennen würden, würde der Empfänger das Gesicht von D. B. wieder sehen, weil es außerhalb des Postings unten dranhängt.
Aber ehrlich... das soll echt nicht UNSER Problem sein. Wir können alles dafür tun, dass bestimmte Inhalte verborgen bleiben, aber nichts daran ändern, wenn andere Dienste das nicht richtig verarbeiten.
Abgesehen davon ist es möglich auch Teile eines Postings zunächst zu verbergen (BTW: beliebig viele Teile), indem man das Spoiler-Tag verwendet. Funktioniert aber zuverlässig halt nur im Grid.Zeichenbegrenzung
Na ja, was soll man sagen?
Hubzilla packt an die 16 Millionen Zeichen. Dieser Artikel hier ist also ein Fliegenschiss mit ca. 24.000 Zeichen. ;-)Textgestaltung
BBcode "Hubzilla-Flavour" bietet umfangreiche Textgestaltungsmöglichkeiten. Leider werden diese vom derzeitigen Beitragseditor nicht alle vereinfacht z.B. über Buttons und Dialoge angeboten. Hier müsste dringend noch nachgebessert werden (könnte mein nächstes Projekt werden). Zumindest verfügt der Editor über eine Autovervollständigung, die hilfreich ist, wenn man weiß, was die BBcode Tags bewirken.
Was Hubzilla von vielen Diensten unterscheidet ist, dass Medien wirklich in den Beitrag eingebettet werden, also an der Stelle erscheinen, wo wir sie unterbringen. Die Anzahl an Medien ist außerdem ebenfalls nicht beschränkt.
Bedenkt aber, wenn Ihr Beiträge ins Fediverse teilt, dass es Dienste gibt, die nicht nur Medien (also z.B. Bilder) hinten anhängen, sondern auch auf wenige (bei Mastodon vier) begrenzen. Es ist deshalb sinnvoll, einen Hinweis auf die tatsächliche Anzahl von Bildern hinzuweisen und dass es erforderlich sein kann, das Original-Posting auf Eurer Heimat-Instanz zu besuchen, um alle Bilder (und die auch noch korrekt eingebettet) sehen zu können. Klingt komisch, ist aber so. ;-) :-DFazit
Kommt einfach ins Grid! Besorgt euch einen Account bei Hubzilla. Ihr könnt das ja zusätzlich zu Eurem aktuellen Fediverse-Account tun. Und importiert Eure Follower-/Following-Liste. Dafür gibt es (sofern der von Euch gewählte Hub das Addon installiert hat) inzwischen ein Addon, das die typischen Exportdateien (csv) von Mastodon und co. verarbeitet. Richtet Euren Kanal so ein, wie Ihr es euch vorstellt und nutzt es.
Es ist durchaus möglich, dass Ihr dann irgendwann immer öfter mit Hubzilla, statt mit dem ursprünglichen Dienst im Fediverse unterwegs seid. Und wenn Ihr dann auch noch Kontakte zu Nutzern im Grid habt, werdet Ihr feststellen, dass die soziale Interaktion damit noch viel komfortabler ist. Vielleicht wagt ja dann irgendwann auch die eine oder andere eurer alten Verbindungen auch den Schritt und Ihr könnt den Komfort gemeinsam genießen.
Anhänge
Wer?
Was?
#hubzilla #zot #nomad #grid #fediverse -
#Bitnami has removed their container images and #Helm charts from 'main' registries like #Docker hub and whatnot for a while now, thanks to fucking #Broadcom - in order to lock them behind some enterprise contract or some shit. But. They've always been 'secretly' available still on some other registries like #Amazon 's #AWS #ECR Public Gallery (
public.ecr.aws). Not anymore, they're planning to remove them on June 10. These fucking bitches.
🔗 https://community.broadcom.com/tanzu/blogs/beltran-rueda-borrego/2026/05/20/important-update-transitioning-bitnami-offerings-o
Everyone in the #homelab/#DevOps community, please, mirror the shit out of their stuffs please before they're gone forever (June 10):
🔗 https://gallery.ecr.aws/bitnami
#Zot is one good OCI registry mirroring tool you could self-host to make this a lil easier:
🔗 https://github.com/project-zot/zot -
#Bitnami has removed their container images and #Helm charts from 'main' registries like #Docker hub and whatnot for a while now, thanks to fucking #Broadcom - in order to lock them behind some enterprise contract or some shit. But. They've always been 'secretly' available still on some other registries like #Amazon 's #AWS #ECR Public Gallery (
public.ecr.aws). Not anymore, they're planning to remove them on June 10. These fucking bitches.
🔗 https://community.broadcom.com/tanzu/blogs/beltran-rueda-borrego/2026/05/20/important-update-transitioning-bitnami-offerings-o
Everyone in the #homelab/#DevOps community, please, mirror the shit out of their stuffs please before they're gone forever (June 10):
🔗 https://gallery.ecr.aws/bitnami
#Zot is one good OCI registry mirroring tool you could self-host to make this a lil easier:
🔗 https://github.com/project-zot/zot -
#Bitnami has removed their container images and #Helm charts from 'main' registries like #Docker hub and whatnot for a while now, thanks to fucking #Broadcom - in order to lock them behind some enterprise contract or some shit. But. They've always been 'secretly' available still on some other registries like #Amazon 's #AWS #ECR Public Gallery (
public.ecr.aws). Not anymore, they're planning to remove them on June 10. These fucking bitches.
🔗 https://community.broadcom.com/tanzu/blogs/beltran-rueda-borrego/2026/05/20/important-update-transitioning-bitnami-offerings-o
Everyone in the #homelab/#DevOps community, please, mirror the shit out of their stuffs please before they're gone forever (June 10):
🔗 https://gallery.ecr.aws/bitnami
#Zot is one good OCI registry mirroring tool you could self-host to make this a lil easier:
🔗 https://github.com/project-zot/zot -
#Bitnami has removed their container images and #Helm charts from 'main' registries like #Docker hub and whatnot for a while now, thanks to fucking #Broadcom - in order to lock them behind some enterprise contract or some shit. But. They've always been 'secretly' available still on some other registries like #Amazon 's #AWS #ECR Public Gallery (
public.ecr.aws). Not anymore, they're planning to remove them on June 10. These fucking bitches.
🔗 https://community.broadcom.com/tanzu/blogs/beltran-rueda-borrego/2026/05/20/important-update-transitioning-bitnami-offerings-o
Everyone in the #homelab/#DevOps community, please, mirror the shit out of their stuffs please before they're gone forever (June 10):
🔗 https://gallery.ecr.aws/bitnami
#Zot is one good OCI registry mirroring tool you could self-host to make this a lil easier:
🔗 https://github.com/project-zot/zot -
#Bitnami has removed their container images and #Helm charts from 'main' registries like #Docker hub and whatnot for a while now, thanks to fucking #Broadcom - in order to lock them behind some enterprise contract or some shit. But. They've always been 'secretly' available still on some other registries like #Amazon 's #AWS #ECR Public Gallery (
public.ecr.aws). Not anymore, they're planning to remove them on June 10. These fucking bitches.
🔗 https://community.broadcom.com/tanzu/blogs/beltran-rueda-borrego/2026/05/20/important-update-transitioning-bitnami-offerings-o
Everyone in the #homelab/#DevOps community, please, mirror the shit out of their stuffs please before they're gone forever (June 10):
🔗 https://gallery.ecr.aws/bitnami
#Zot is one good OCI registry mirroring tool you could self-host to make this a lil easier:
🔗 https://github.com/project-zot/zot -
Zot now supports Claude Opus 4.8
#HackerNews #Zot #ZotSupport #ClaudeOpus48 #TechUpdates #SoftwareDevelopment
-
Zot now supports Claude Opus 4.8
#HackerNews #Zot #ZotSupport #ClaudeOpus48 #TechUpdates #SoftwareDevelopment
-
Zot now supports Claude Opus 4.8
#HackerNews #Zot #ZotSupport #ClaudeOpus48 #TechUpdates #SoftwareDevelopment
-
Zot now supports Claude Opus 4.8
#HackerNews #Zot #ZotSupport #ClaudeOpus48 #TechUpdates #SoftwareDevelopment
-
Zot now supports Claude Opus 4.8
#HackerNews #Zot #ZotSupport #ClaudeOpus48 #TechUpdates #SoftwareDevelopment
-
@Kristian Na ja, Friendica war ja ausgereift. Zumindest soweit ausgereift, wie Friendica selbst und das DFRN-Protokoll es zuließen. Smartphone-Apps gab es nicht, weil man damals, 2010/2011, Smartphone-Apps für Sachen, die es auch als Websites gab, noch als Gimmicks ansah und noch nicht als lebensnotwendig. Das war, bevor die Leute gewisse Websites mehr über dedizierte Apps nutzten als über die Websites selbst.
Nur: Eine Weiterentwicklung war zwingend notwendig. Und die ging nicht mit Friendica, wie es war, denn die ging auch nicht mit DFRN.
Der Auslöser: 2011 waren binnen kurzer Zeit mehrere größere Friendica-Nodes von jetzt auf sofort ohne Ankündigung verschwunden. Einfach so weg. Friendica war durch das Verschwinden einiger weniger, aber jeweils sehr großer öffentlicher Nodes auf die Hälfte seiner Größe geschrumpft. Die andere Hälfte der Nutzer hatte alles verloren ohne die Chance, irgendwas zu retten. Die konnten wieder ganz neu bei null anfangen.
Das beste, was Mike an Friendica selbst machen konnte, war, eine Export- und Importfunktion einzubauen. Damit konnte man Backups des eigenen Konto machen. Das half aber nur, wenn man entweder brav ein tägliches Backup machte oder die Schließung eines Node vorher angekündigt wurde. Noch einmal: Genau das war 2011 nicht passiert. Die Nodes waren einfach futsch. Da hilft dir auch eine Backup-Funktion nicht, wenn du nicht laufend regelmäßig Backups machst.
Mike sah nur eine mögliche wirkliche Lösung. Und das war, indem deine Identität nicht bombenfest an einen Server gebunden ist, sondern simultan gleichzeitig als identische Klone auf mehreren unabhängigen Servern existieren kann. Wenn davon mal einer ausfällt, egal, die anderen laufen ja noch, also läuft deine Identität noch.
Problem: Mit DFRN ging das nicht umzusetzen. Es brauchte ein ganz neues Protokoll. Auch deshalb, weil Mike noch andere Verbesserungen im Kopf hatte wie ein nochmals deutlich aufgebohrtes Berechtigungssystem. Auch das ging mit DFRN so nicht und brauchte ein neues Protokoll. So entstand Zot.
Zum einen hieß ein neues Protokoll aber auch, wo auch immer das eingebaut werden soll, muß das komplette Backend ausgetauscht und neu geschrieben werden. Und große Teile des Frontend gleich mit. Das konnte Mike aber nicht auf Friendica im laufenden Betrieb machen. Friendica hätte unmöglich seine Grundfunktionalität gleichzeitig auf DFRN und auf Zot betreiben können. Und ein Protokollaustausch hätte bedeutet, daß Nodes, die die neue Friendica-Version mit Zot fahren, sich nicht mehr nativ hätten verbinden können mit Nodes, die alte Versionen mit DFRN fahren. Die wären zueinander inkompatibel gewesen.
Mike hatte als neue Entwicklungsplattform ja gerade das neue Red, das ein Fork seiner bisherigen "geheimen" Entwicklungsplattform Free-Friendika war. Das war ebenso "geheim", das konnte er also entsprechend umbauen.
Mike hätte aber niemals gleichzeitig Red komplett umbauen und Friendica selbst auf Free-Friendika weiterpflegen und die Weiterentwicklungen von Free-Friendika nach Friendica selbst bringen können. Und die einzige Alternative zum Umbau von Red auf Zot war, wieder solche Massencrashs wie 2011 mit exakt denselben Auswirkungen zu haben, ohne irgendwas tun zu können.
Also hat Mike sich auf Red konzentriert (dessen Umbau ja alleine schon länger dauern sollte als die Entwicklung von Friendica) und Friendica in die Hände von Tobias und Michael gegeben, die es seitdem nach ihren Vorstellungen weiterentwickeln. Die beiden waren ja meines Wissens sowieso schon Co-Entwickler von Friendica. Das hat Mike ja längst nicht mehr alles alleine gemacht.
Bei Red war das wieder anders. Das machte Mike ganz alleine. Das mußte er ja erstmal aufbauen. Und selbst als es fertig war, wurde es kaum angenommen. Es war zwar kein Geheimprojekt mehr, nachdem es sich von Friendica gelöst hatte. Aber es wurde kaum angenommen.
Auch als es umbenannt wurde in Red Matrix, was es leichter machte, es zu googlen, wurde es nicht angenommen. Die Friendica-Nutzer nahmen es wahr als Friendica mit nomadischer Identität. Was nomadische Identität ist, verstanden sie gar nicht. Selbst wenn doch: Die meisten von ihnen hatten inzwischen ihre eigenen privaten Einzelnutzer-Nodes.
So sahen sie in der Red Matrix gegenüber Friendica keine Vorteile, also warum umsteigen? Mal ganz davon abgesehen, daß Friendica und die Red Matrix nur über das diaspora*-Protokoll oder OStatus kommunizieren konnten. Die einzigen, die wechselten, dürften die gewesen sein, die eh immer das neueste, heißeste Zeug ausprobieren wollten.
Außerhalb von Friendica wußte eh keine Sau, daß die Red Matrix existierte. Herzlich wenige Leute wußten ja überhaupt auch nur, daß Friendica existierte. Mikes "Wenn du es baust, werden sie kommen" funktionierte damals schon nicht. Kleckerweise kamen noch neue Leute nach Friendica. Aber kaum einer ging von Friendica auf die Red Matrix, und absolut niemand ging von null auf die Red Matrix.
Interessant wurde die Red Matrix eigentlich erst 2015, als sie zu Hubzilla aufgebohrt wurde, also auf einmal Sachen konnte, die Friendica nicht konnte, die aber vielleicht nützlich sein konnten. Damit konnte Hubzilla auch für ganz andere Sachen eingesetzt werden als Friendica, also nicht nur als Facebook-Ersatz oder Blog.
Aber wenn Mario schon Anfang 2015 das noch brandneue Hubzilla übernahm, was ja so auf der offiziellen Website steht (nach meinen Informationen war es erst 2018), dann war es ein Wunder, daß Mike überhaupt jemanden fand, der übernehmen würde, der also schon seit Red-Matrix-Zeiten dabei war. Aber Mike hat ja an der Weiterentwicklung von Hubzilla noch weiter aktiv mitgewirkt, nur eben nicht als Projektleiter.
Hubzilla selbst wurde ja erst ab Ende 2015 interessant, als es seinen ersten stabilen Release hatte. Und auch Hubzillas Existenz war eigentlich nur auf Friendica bekannt. Selbst heute noch sind die allermeisten Hubzilla-Nutzer Friendica-Veteranen. Direkt von Mastodon nach Hubzilla ist kaum einer gekommen, von null nach Hubzilla schon gar nicht.
Selbst da war Mike keiner, der Sachen so läßt, wie sie sind, und sie nur noch weiter poliert. Wenn es etwas zu verbessern gibt, dann macht er das auch. Und wenn das nicht auf existierender Software im laufenden Produktivbetrieb geht, dann forkt er eben, und dann nimmt er sich weit mehr Zeit für seinen Fork als für das, was er vorher gemacht hatte. Und das ist auch gut so. Ansonsten hätten wir heute noch nur Friendica und immer noch keine Lösung für das Problem, daß die Leute alles verlieren, wenn mal wieder ein großer Node verschwindet.
Jetzt wollte Mike Zot weiterentwickeln, wohl auch deshalb, weil Zot, wie es damals war, nicht gut mit ActivityPub zusammenspielte. Aber potentiell kompatibilitätsbrechend. In einem eigenen zusätzlichen Branch von Hubzilla wäre das nicht gegangen, schon deshalb, weil Hubzilla für solche Experimente schlicht und ergreifend zu groß war.
Also hat Mike 2018 Osada von Hubzilla abgeforkt und alles rausgerissen, was im Weg war. Artikel, Karten, Wikis, Webpages, alle Verbindungsmöglichkeiten außer Zot, ActivityPub und RSS/Atom, alles raus.
Weil dann abzusehen war, daß nomadisches Zot6 (zumindest vorerst) mit ActivityPub überhaupt nicht mehr funktionieren würde, brauchte Mike zwei Projekte: Osada behielt ActivityPub, wurde aber nichtnomadisch. Zusätzlich forkte er Zap von Osada, ließ es nomadisch, entfernte aber ActivityPub.
Jetzt konnte Mike endgültig nicht gleichzeitig Zot6 entwickeln und Osada entwickeln und Zap entwickeln und Hubzilla weiterpflegen. Auch dieses Mal half ihm bei den Neuentwicklungen niemand. Also überließ er Hubzilla gänzlich Mario.
Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.
Anfang 2019 fand er einen Weg, auch nomadisches Zot6 mit ActivityPub kompatibel zu machen. Abgesehen davon war die Idee, einen nomadischen Zap-Kanal über einen nichtnomadischen Osada-Kanal mit dem Fediverse zu verbinden, sowieso kompletter Blödsinn und technisch in der Praxis kaum realisierbar, selbst mit Kanalquellen nicht. Also stellte Mike Osada ein, forkte von Zap ein ganz neues Osada und baute da ActivityPub-Support ein. Noch war nomadisches Zot6 + ActivityPub ja noch experimentell, deswegen hat er es nicht in Zap eingebaut.
Dann aber wurden Osada und Zap stabil und bekamen sogar einen 1.0-Release. Inzwischen gab es Leute, die Osada oder Zap produktiv nutzten. Die kamen alle von Hubzilla, denn nur da wußte man, daß es Osada und Zap gab. Nicht mal auf Friendica wußte das jemand, im übrigen Fediverse erst recht nicht und außerhalb des Fediverse schon gar nicht.
So baute Mike dann Osadas ActivityPub-Support auch in Zap ein, schaltete ihn aber standardmäßig auf Serverebene ab, auf Kanalebene sowieso. Das führte dazu, daß Osada und Zap bis auf das Branding und die Standardeinstellungen völlig identisch waren. Es brauchte gar nicht mehr beide. Mike ließ das aber so.
Irgendwie gab es wohl genug Osada- und Zap-Anwender, daß Mike jemanden fand, der beides weiterpflegen wollte. Denn Mike hatte wieder neue Weiterentwicklungen im Sinne, die er aber nicht mehr auf Osada und Zap machen konnte, weil die jetzt beide als stabile Produktivsoftware galten. So gab er Osada und Zap dann wieder an "die Community" weiter, die als quasi erste Amtshandlung mit Mikes Segen Osada nach Zap mergete, in dem Zuge auch auf Zap ActivityPub standardmäßig aktivierte und Osada kurzerhand einstellte.
2020 ging es dann weiter. Zap war damals State of the Art. Zot6 war so stabil, daß es nach Hubzilla zurückportiert wurde. Zap war jetzt quasi der modernere kleine Bruder von Hubzilla, der sich etwas eleganter bediente und einen nicht mit Features erschlug. Nur war Zap immer noch obskurer als Hubzilla, Hubzilla war obskurer als Friendica, und Friendica war selbst sehr obskur, weil für keins der drei wirklich Werbung gemacht wurde. Zap war weiterhin sonst nur auf Hubzilla bekannt und Hubzilla sonst nur auf Friendica.
Und Mike bastelte an Zot8, das nochmals besser werden sollte. Dafür brauchte er aber Software zum Experimentieren. Und so entstanden drei neue Forks in so kurzer Folge, daß heute nicht mehr bekannt ist, was jetzt wovon geforkt wurde, nur daß irgendwas von Zap geforkt worden ist. Im einzelnen waren das schon wieder ein neues Osada, ein neues Mistpark und eine neue Redmatrix.
Warum drei?
Es ging das Gerücht um, das seien verschiedene Stabilitätsstufen. Redmatrix 2020 sei experimentell mit wie früher bei Zap standardmäßig deaktiviertem ActivityPub, das damit der Entwicklung von Zot8 nicht im Wege stehe. Osada sei auch experimentell, aber wie früher schon bei Osada mit standardmäßig aktiviertem ActivityPub, um zu gucken, wie die Weiterentwicklungen von Zot8 sich mit ActivityPub vertragen. Mistpark 2020 wiederum sei "halbstabil" wie Debian testing, also stabiler als Osada und eher für den Produktiveinsatz geeignet, aber aktueller als Zap.
Zap sei also für die, die etwas neueres als Hubzilla haben wollten und auf die Zusatzfeatures von Hubzilla verzichten konnten. Misty sei für die, die etwas noch aktuelleres als Zap haben wollten, also das neueste Zeug noch früher, und die etwaige Instabilitäten in Kauf zu nehmen bereit waren. Osada sei für die, die unbedingt bleeding-edge wollten, instabil oder nicht. Und Redmatrix 2020 sei eh nur für Mike.
In Wahrheit waren Osada, Misty und Redmatrix 2020 bis auf das Branding völlig identisch und quasi Soft-Forks. Alle Commits wurden gleichermaßen und fast gleichzeitig in alle drei eingepflegt.
Warum?
Weil Mike der Markenfetischismus im Fediverse auf den Keks ging. Es gab Leute, die bildeten sich ein, die Software, die sie nutzten, sei die beste, einfach, weil sie Fans der Softwaremarke waren. Ganz besonders gab es die natürlich auf Mastodon, aber auch sonst. Genau diese Leute wollte er trollen, indem er drei bis auf den Namen und das Logo völlig identische Serveranwendungen pflegte. Misty z. B. konnte überhaupt nicht "die beste Fediverse-Serversoftware" sein, egal, wer sich das einbildete, wenn Osada und Redmatrix bis auf die Marke völlig baugleich waren.
Anfang 2021 kam dann Roadhouse dazu. Das Abenteuer Zot8 war im Grunde vorbei, bevor Zot8 stabil war. Denn Zot11 sollte noch besser werden. Vor allem sollte Zot11 von allen Zot-Versionen die beste Kompatibilität mit ActivityPub bekommen. Blöderweise konnte Mike aber Zot11 nicht auf Osada, Misty und Redmatrix entwickeln. Zot11 sollte nämlich zu allen Vorgängern so inkompatibel werden, daß es letztlich nicht mehr Zot heißen sollte. Aber es gab Leute, die Osada, Misty oder Redmatrix produktiv nutzten.
Also mußte Mike von einem von den dreien Roadhouse forken. War ihm aber egal, weil er damit die Leute mit noch einer weiteren Marke trollen konnte. Wohlgemerkt, effektiv hatte er sogar Zap noch an der Backe, weil es in der Community dann wohl doch zuwenig Interesse an der Weiterentwicklung gab.
Nomad, eigentlich ja Zot11, wurde zum Erfolg. Und das Erfolgsrezept lag auch darin, zusätzlich Support für Hubzillas Zot6 einzubauen, über den Roadhouse auch mit Osada, Misty und Redmatrix kommunizieren konnte. Ansonsten waren von den praktischen Features her Zap, Osada, Misty, Redmatrix und Roadhouse identisch und von der Benutzeroberfläche her auch beinahe. Es machte in der Praxis keinen großen Unterschied, welches man nutzte. Außerhalb waren sie eh, wenn überhaupt, nur auf Hubzilla bekannt. Das heißt, Roadhouse war beinahe komplett unbekannt, weil da endgültig nur Mike drüber redete.
Daß es (streams) gibt, obwohl Roadhouse doch gut war, hatte andere Gründe.
Grund 1: Mike fand einen neuen Weg, die Markenfetischisten zu trollen. Nämlich mit Software, die gar keinen Namen und gar keine Markenidentität hat. Also nahm Mike dem neuen Roadhouse-Fork von Ende 2021 den Namen und sogar den fediverseinternen festen Identifikator weg. Letzteren kann man entweder händisch ausfüllen, oder (streams) übernimmt ihn vom Instanznamen. Alleine das wäre mit einem "Debranding" von Roadhouse nicht getan gewesen, weil weiter alle von "Roadhouse" gesprochen hätten.
Grund 2: Dieses ständige Wetteifern, welche Software auf The Federation, Fediverse Observer, der FediDB usw. jetzt am populärsten ist und am meisten genutzt wird, ging ihm inzwischen auch auf dem Zeiger. Ein weiteres "Feature" von (streams) ist, daß Mike neben dem Namen und der Markenidentität auch nodeinfo praktisch komplett entfernt hat. (streams) sendet überhaupt keine Statistiken und hält sich von allen Instanzlisten-Websites fern. Und das ist so gewollt.
Grund 3: Zusätzlich wollte Mike es der Free-Software- und Open-Source-Community leichter machen. Da kloppt man sich ja bekanntlich darum, welche Lizenzen wirklich frei sind und welche nicht. Also hat Mike (streams), dessen sämtliche Vorgänger unter der MIT-Lizenz stehen, in die Public Domain gestellt. Freier als das geht's nun wirklich nicht mehr. Gleichzeitig wollte Mike diejenigen ärgern, die vielleicht vorhaben könnten, aus (streams) proprietäre, kommerzielle Closed-Source-Software zu machen. Die ganzen Apps sind nämlich durchaus schon mal Fremdcode und stehen unter eigenen Lizenzen. Und die sind untereinander inkompatibel.
(streams) sollte stabil werden und wurde stabil. Im Grunde war Mikes Plan, (streams) zu der Fediverse-Software der Zukunft zu machen. So hat er am 31.12.2022 offiziell Zap, Osada, Misty, Redmatrix und Roadhouse eingestellt. Das war aber kein Problem, denn zwischen den fünfen konnten Admins durch einfaches Rebasen nicht nur crossgraden, sondern auch zu (streams) upgraden.
Jetzt gab es nur noch Friendica, Hubzilla und (streams), wovon Mike nur noch (streams) betreute.
Dann kam ja silverpill auf Mike zu mit der Idee der nomadischen Identität über ActivityPub. Mike war interessiert. silverpill trieb das ziemlich voran inklusive dem einen oder anderen neuen FEP, darunter auch FEP-ef61, das in ActivityPub dezentrale Identitäten einführen sollte. Zot hat so etwas, Nomad natürlich auch, aber anders, und ActivityPub hatte das natürlich nicht.
Diese dezentralen Identitäten hat Mike auch in (streams) eingebaut. Langfristig sollte es ja möglich sein, zwischen verschiedenen Serveranwendungen zu klonen, so auch zwischen (streams) und Mitra. Zumindest aber sollten sie voneinander die dezentralen Identitäten als ebensolche verstehen. So sollte (streams) geklonte Mitra-Identitäten als solche erkennen, und Mitra sollte geklonte (streams)-Kanäle als solche erkennen.
Unter Laborbedingungen in Mikes nomadic-Zweig funktionierten die. Also mergete Mike im Juni 2024 den nomadic-Zweig in den dev-Zweig, den allgemeinen Entwicklungszweig. Auch der lief nur unter Laborbedingungen, weil (im Gegensatz zu Hubzilla, wo zwei öffentliche Produktivhubs Entwicklerversionen fahren) niemand außer Mike den dev-Zweig von (streams) produktiv fuhr.
Im Juli 2024 mergete Mike dann den dev-Zweig in den release-Zweig, um die neuesten Weiterentwicklungen an die produktiv gefahrenen, stabilen Server auszurollen. Da war allerdings Schluß mit Laborbedingungen. Jetzt mußten sich FEP-ef61 und die DIDs unter täglichen und breitgefächerten Realbedingungen beweisen.
Genau das taten sie nicht. Erst jetzt stellte sich heraus, daß (streams) mit den vielen Identitäten nicht klarkam. Es föderierte nicht mehr über ActivityPub. Es föderierte nicht mehr mit Hubzilla. Es föderierte nicht mal mehr mit sich selbst. Es konnte sich mit nichts mehr vernünftig verbinden.
Mike brauchte eine Weile, um überhaupt festzustellen, daß der Verursacher dieser Misere ein Identitätenchaos war. Das konnte er aber nicht auf (streams) selbst beheben. Hilfe hatte er auch keine. Die (streams)-Community war so winzig, da gab es niemanden, der ihm hätte helfen können. Der einzige, der die Fähigkeit gehabt hätte, hatte keine Zeit. Und der einzige, der Zeit und Bock hatte, hatte vom Coden keine Ahnung.
So mußte Mike sich erstmal einen Überblick verschaffen. Im August, also dem Monat nach dem Crash, als der Crash noch nicht behoben war, forkte er das streams-Repository und schuf Forte. Da wiederum riß er alles raus, was nicht ActivityPub war, also die Unterstützung sowohl von Nomad als auch von Zot6, um einen freien, ungehinderten Blick auf ActivityPub zu haben.
Inzwischen hatte er auch zwei andere Sachen gelernt: Software, die keinen Namen hat, interessiert keinen. Das verwirrt die Leute eher. Also bekam Forte wieder einen Namen. Die Public Domain brachte auch nichts. Also kam Forte wieder unter die MIT-Lizenz. Und Fediverse-Software, die überhaupt keine nodeinfo hat, ist praktisch unsichtbar. Also bekam Forte wieder nodeinfo, zunächst aber, ohne brauchbare Zahlen zu versenden. So konnte Forte zumindest vom Fediverse Observer und später vom FediIndex gelistet werden.
Forte half ihm, die ID-Misere zu entwirren, zu entflechten und zu lösen. Das reichte er dann auch nach (streams) weiter, das allmählich wieder funktionierte. Allerdings brannte er sich in dem August derart aus, daß er zum 31.8.2024 offiziell sowohl das streams-Repository als auch Forte zur Übernahme anbot und seinen Ruhestand ankündigte.
Dieses Mal fand eine Übernahme gleich gar nicht statt. Wie gesagt, in der (streams)-Community gab es niemanden, der sowohl die Zeit als auch das Know-how hatte, um auch nur Mike zu helfen, geschweige denn, eine Rolle wie Tobias oder Michael oder Mario anzunehmen.
Außerhalb von (streams) war (streams) selbst sogar auf Hubzilla kaum bekannt. Forte war sogar auf Hubzilla noch unbekannter, zumal es noch eine obskure, nichtöffentliche Bastelbude war, bis Mike im September 2024 die erste "offizielle" Entwicklerversion von Forte (und damit Forte selbst) veröffentlichte.
Und außerhalb von Hubzilla? Mike war es so leid, daß Mastodon als alternativlose Referenzimplementation des Fediverse angesehen wurde, daß er um 2023 anfing, Werbung für (streams) zu machen. Das erste Mal überhaupt, daß Mike von "wenn du es baust, werden sie kommen" abkam (es kam ja keiner) und irgendwas bewarb. Nur wußte Mike nicht, wie man zu Mastodon-Leuten spricht; ehrlich gesagt, das weiß auch auf Friendica und Hubzilla kaum jemand.
Oft genug ging aus Mikes Posts nicht mal hervor, daß er über ein konkretes Fediverse-Produkt sprach, und schon gar nicht, über welches. Wie auch, sprach er doch von etwas Namenlosem. Das heißt, auch er fing langsam an, den Namen des Repository zu verwenden. Aber er machte nicht unbedingt wirklich glasklar, daß er von etwas sprach, das jetzt in diesem Augenblick im Fediverse existierte. Schon gar nicht erwähnte er, daß es auch mit Mastodon verbunden ist, denn kaum jemand außerhalb von Mastodon weiß, daß Mastodon-Nutzer das nicht unbedingt automatisch verstehen.
Stand Mitte September 2024 hatte (streams) keine 100 aktiven Nutzer und Forte außer Mike gar keine. Traurigerweise hatte (streams) damals mehr öffentliche Server als heute, derweil Forte anderthalb Jahre gebraucht hat, um auch nur einen hervorzubringen. Wo sollen da Entwickler herkommen?
Mike hat übrigens nicht vor, (streams) einzustellen. Er und nicht nur er sagt, (streams) hat weiterhin seine Existenzberechtigung, und zwar als moderne Fediverse-Software, die von ActivityPub unabhängig ist. Er und nicht nur er sieht den ActivityPub-Schalter als eine Art letztes Bollwerk gegen Mastodon an und das einzige, das auf Kanalebene funktioniert, also nicht nur serverweit.
So, nun noch das Wort zu Smartphone-Apps.
Von Mike selbst war da nie etwas zu erwarten. Fediverse-Apps sind reine Frontend-Sachen. Und wir sollten inzwischen wissen, daß Mike nicht mal Web-UIs kann. Hubzilla ist für seine Oberfläche berüchtigt. Es ist doch erst schick geworden, als Saiwal mit seinen Utsukta-Themes anfing.
Außerdem hatte Mike immer schon genügend mit Webentwicklung zu tun. Da konnte man von ihm nicht auch noch erwarten, eine Smartphone-App zu entwickeln. Besser gesagt, zwei Smartphone-Apps, weil die iOS-App wahrscheinlich separat hätte entwickelt werden müssen. Mike wäre ja auch keiner gewesen, der in einer Smartphone-App nur das nötigste an Features eingebaut hätte. Wenn, dann alles. Er hätte also neben der Serversoftware zwei ziemliche Monster-Apps entwickeln und pflegen müssen.
Apps von Drittentwicklern?
Guck dir mal an, wie lange es gedauert hat, bis es von RaccoonForFriendica einen öffentlich verfügbaren Android-Release gab. Für iOS ist es meines Wissens bis heute nur über TestDrive verfügbar, aber nicht im App Store. Und selbst auf Android ist es noch nicht so stabil und fully featured, daß man es als Daily Driver nutzen könnte.
Für Hubzilla gab es mal Nomad für Android. Das wird seit gut sechs Jahren nicht mehr weiterentwickelt. Unter aktuellen Android-Versionen läuft es inzwischen gar nicht mehr. Und auch das ist nur ein Wrapper für die Weboberfläche, also ein glorifizierter Webbrowser. Ansonsten gibt's nur eine Minimalst-App von Mario, mit der er mal versuchsweise getestet hat, ob man von Android aus nach Hubzilla posten kann. Das ist absolut das einzige, was die App überhaupt kann.
Hubzilla hat eine Client API. Ob die aber funktioniert, ist weitestgehend unbekannt, weil noch nie jemand versucht hat, dagegen eine hinreichend mit Features ausgestattete App zu bauen. Dasselbe dürfte für (streams) und Forte gelten, für die es überhaupt noch nie irgendwelche Apps gegeben hat. Alle drei setzen statt dessen auf den Einsatz als PWA, nur daß da draußen keine Sau weiß, daß es das überhaupt gibt, geschweige denn, wie man das einrichtet.
Auf Drittentwickler kann man hier erst recht nicht hoffen. Von den Leuten im Fediverse, die Smartphone-Apps entwickeln können, kennt genau niemand Hubzilla, geschweige denn (streams) oder Forte. Selbst wenn sie Hubzilla kennenlernen würden, hätten sie keinen Bock, dafür eine App zu entwickeln. Lohnt sich nicht, weil nutzt keiner. Es lohnt sich viel mehr, die drölfzigtausendste reine Mastodon-App fürs iPhone zu bauen. Das heißt, mindestens die Hälfte von denen weiß doch sowieso nicht, was es außer Mastodon sonst noch so im Fediverse gibt.
Auf Hubzilla selbst gibt's nicht einen Mobilentwickler. Auf (streams) und Forte dürfte es niemanden geben, der überhaupt wirklich irgendwas entwickeln kann, nicht mal Webanwendungen (sonst hätte Mike Hilfe), Smartphone-Apps schon gar nicht.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendica #RedMatrix #Hubzilla #Osada #Zap #Roadhouse #Streams #(streams) #Forte -
@Kristian Na ja, Friendica war ja ausgereift. Zumindest soweit ausgereift, wie Friendica selbst und das DFRN-Protokoll es zuließen. Smartphone-Apps gab es nicht, weil man damals, 2010/2011, Smartphone-Apps für Sachen, die es auch als Websites gab, noch als Gimmicks ansah und noch nicht als lebensnotwendig. Das war, bevor die Leute gewisse Websites mehr über dedizierte Apps nutzten als über die Websites selbst.
Nur: Eine Weiterentwicklung war zwingend notwendig. Und die ging nicht mit Friendica, wie es war, denn die ging auch nicht mit DFRN.
Der Auslöser: 2011 waren binnen kurzer Zeit mehrere größere Friendica-Nodes von jetzt auf sofort ohne Ankündigung verschwunden. Einfach so weg. Friendica war durch das Verschwinden einiger weniger, aber jeweils sehr großer öffentlicher Nodes auf die Hälfte seiner Größe geschrumpft. Die andere Hälfte der Nutzer hatte alles verloren ohne die Chance, irgendwas zu retten. Die konnten wieder ganz neu bei null anfangen.
Das beste, was Mike an Friendica selbst machen konnte, war, eine Export- und Importfunktion einzubauen. Damit konnte man Backups des eigenen Konto machen. Das half aber nur, wenn man entweder brav ein tägliches Backup machte oder die Schließung eines Node vorher angekündigt wurde. Noch einmal: Genau das war 2011 nicht passiert. Die Nodes waren einfach futsch. Da hilft dir auch eine Backup-Funktion nicht, wenn du nicht laufend regelmäßig Backups machst.
Mike sah nur eine mögliche wirkliche Lösung. Und das war, indem deine Identität nicht bombenfest an einen Server gebunden ist, sondern simultan gleichzeitig als identische Klone auf mehreren unabhängigen Servern existieren kann. Wenn davon mal einer ausfällt, egal, die anderen laufen ja noch, also läuft deine Identität noch.
Problem: Mit DFRN ging das nicht umzusetzen. Es brauchte ein ganz neues Protokoll. Auch deshalb, weil Mike noch andere Verbesserungen im Kopf hatte wie ein nochmals deutlich aufgebohrtes Berechtigungssystem. Auch das ging mit DFRN so nicht und brauchte ein neues Protokoll. So entstand Zot.
Zum einen hieß ein neues Protokoll aber auch, wo auch immer das eingebaut werden soll, muß das komplette Backend ausgetauscht und neu geschrieben werden. Und große Teile des Frontend gleich mit. Das konnte Mike aber nicht auf Friendica im laufenden Betrieb machen. Friendica hätte unmöglich seine Grundfunktionalität gleichzeitig auf DFRN und auf Zot betreiben können. Und ein Protokollaustausch hätte bedeutet, daß Nodes, die die neue Friendica-Version mit Zot fahren, sich nicht mehr nativ hätten verbinden können mit Nodes, die alte Versionen mit DFRN fahren. Die wären zueinander inkompatibel gewesen.
Mike hatte als neue Entwicklungsplattform ja gerade das neue Red, das ein Fork seiner bisherigen "geheimen" Entwicklungsplattform Free-Friendika war. Das war ebenso "geheim", das konnte er also entsprechend umbauen.
Mike hätte aber niemals gleichzeitig Red komplett umbauen und Friendica selbst auf Free-Friendika weiterpflegen und die Weiterentwicklungen von Free-Friendika nach Friendica selbst bringen können. Und die einzige Alternative zum Umbau von Red auf Zot war, wieder solche Massencrashs wie 2011 mit exakt denselben Auswirkungen zu haben, ohne irgendwas tun zu können.
Also hat Mike sich auf Red konzentriert (dessen Umbau ja alleine schon länger dauern sollte als die Entwicklung von Friendica) und Friendica in die Hände von Tobias und Michael gegeben, die es seitdem nach ihren Vorstellungen weiterentwickeln. Die beiden waren ja meines Wissens sowieso schon Co-Entwickler von Friendica. Das hat Mike ja längst nicht mehr alles alleine gemacht.
Bei Red war das wieder anders. Das machte Mike ganz alleine. Das mußte er ja erstmal aufbauen. Und selbst als es fertig war, wurde es kaum angenommen. Es war zwar kein Geheimprojekt mehr, nachdem es sich von Friendica gelöst hatte. Aber es wurde kaum angenommen.
Auch als es umbenannt wurde in Red Matrix, was es leichter machte, es zu googlen, wurde es nicht angenommen. Die Friendica-Nutzer nahmen es wahr als Friendica mit nomadischer Identität. Was nomadische Identität ist, verstanden sie gar nicht. Selbst wenn doch: Die meisten von ihnen hatten inzwischen ihre eigenen privaten Einzelnutzer-Nodes.
So sahen sie in der Red Matrix gegenüber Friendica keine Vorteile, also warum umsteigen? Mal ganz davon abgesehen, daß Friendica und die Red Matrix nur über das diaspora*-Protokoll oder OStatus kommunizieren konnten. Die einzigen, die wechselten, dürften die gewesen sein, die eh immer das neueste, heißeste Zeug ausprobieren wollten.
Außerhalb von Friendica wußte eh keine Sau, daß die Red Matrix existierte. Herzlich wenige Leute wußten ja überhaupt auch nur, daß Friendica existierte. Mikes "Wenn du es baust, werden sie kommen" funktionierte damals schon nicht. Kleckerweise kamen noch neue Leute nach Friendica. Aber kaum einer ging von Friendica auf die Red Matrix, und absolut niemand ging von null auf die Red Matrix.
Interessant wurde die Red Matrix eigentlich erst 2015, als sie zu Hubzilla aufgebohrt wurde, also auf einmal Sachen konnte, die Friendica nicht konnte, die aber vielleicht nützlich sein konnten. Damit konnte Hubzilla auch für ganz andere Sachen eingesetzt werden als Friendica, also nicht nur als Facebook-Ersatz oder Blog.
Aber wenn Mario schon Anfang 2015 das noch brandneue Hubzilla übernahm, was ja so auf der offiziellen Website steht (nach meinen Informationen war es erst 2018), dann war es ein Wunder, daß Mike überhaupt jemanden fand, der übernehmen würde, der also schon seit Red-Matrix-Zeiten dabei war. Aber Mike hat ja an der Weiterentwicklung von Hubzilla noch weiter aktiv mitgewirkt, nur eben nicht als Projektleiter.
Hubzilla selbst wurde ja erst ab Ende 2015 interessant, als es seinen ersten stabilen Release hatte. Und auch Hubzillas Existenz war eigentlich nur auf Friendica bekannt. Selbst heute noch sind die allermeisten Hubzilla-Nutzer Friendica-Veteranen. Direkt von Mastodon nach Hubzilla ist kaum einer gekommen, von null nach Hubzilla schon gar nicht.
Selbst da war Mike keiner, der Sachen so läßt, wie sie sind, und sie nur noch weiter poliert. Wenn es etwas zu verbessern gibt, dann macht er das auch. Und wenn das nicht auf existierender Software im laufenden Produktivbetrieb geht, dann forkt er eben, und dann nimmt er sich weit mehr Zeit für seinen Fork als für das, was er vorher gemacht hatte. Und das ist auch gut so. Ansonsten hätten wir heute noch nur Friendica und immer noch keine Lösung für das Problem, daß die Leute alles verlieren, wenn mal wieder ein großer Node verschwindet.
Jetzt wollte Mike Zot weiterentwickeln, wohl auch deshalb, weil Zot, wie es damals war, nicht gut mit ActivityPub zusammenspielte. Aber potentiell kompatibilitätsbrechend. In einem eigenen zusätzlichen Branch von Hubzilla wäre das nicht gegangen, schon deshalb, weil Hubzilla für solche Experimente schlicht und ergreifend zu groß war.
Also hat Mike 2018 Osada von Hubzilla abgeforkt und alles rausgerissen, was im Weg war. Artikel, Karten, Wikis, Webpages, alle Verbindungsmöglichkeiten außer Zot, ActivityPub und RSS/Atom, alles raus.
Weil dann abzusehen war, daß nomadisches Zot6 (zumindest vorerst) mit ActivityPub überhaupt nicht mehr funktionieren würde, brauchte Mike zwei Projekte: Osada behielt ActivityPub, wurde aber nichtnomadisch. Zusätzlich forkte er Zap von Osada, ließ es nomadisch, entfernte aber ActivityPub.
Jetzt konnte Mike endgültig nicht gleichzeitig Zot6 entwickeln und Osada entwickeln und Zap entwickeln und Hubzilla weiterpflegen. Auch dieses Mal half ihm bei den Neuentwicklungen niemand. Also überließ er Hubzilla gänzlich Mario.
Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.
Anfang 2019 fand er einen Weg, auch nomadisches Zot6 mit ActivityPub kompatibel zu machen. Abgesehen davon war die Idee, einen nomadischen Zap-Kanal über einen nichtnomadischen Osada-Kanal mit dem Fediverse zu verbinden, sowieso kompletter Blödsinn und technisch in der Praxis kaum realisierbar, selbst mit Kanalquellen nicht. Also stellte Mike Osada ein, forkte von Zap ein ganz neues Osada und baute da ActivityPub-Support ein. Noch war nomadisches Zot6 + ActivityPub ja noch experimentell, deswegen hat er es nicht in Zap eingebaut.
Dann aber wurden Osada und Zap stabil und bekamen sogar einen 1.0-Release. Inzwischen gab es Leute, die Osada oder Zap produktiv nutzten. Die kamen alle von Hubzilla, denn nur da wußte man, daß es Osada und Zap gab. Nicht mal auf Friendica wußte das jemand, im übrigen Fediverse erst recht nicht und außerhalb des Fediverse schon gar nicht.
So baute Mike dann Osadas ActivityPub-Support auch in Zap ein, schaltete ihn aber standardmäßig auf Serverebene ab, auf Kanalebene sowieso. Das führte dazu, daß Osada und Zap bis auf das Branding und die Standardeinstellungen völlig identisch waren. Es brauchte gar nicht mehr beide. Mike ließ das aber so.
Irgendwie gab es wohl genug Osada- und Zap-Anwender, daß Mike jemanden fand, der beides weiterpflegen wollte. Denn Mike hatte wieder neue Weiterentwicklungen im Sinne, die er aber nicht mehr auf Osada und Zap machen konnte, weil die jetzt beide als stabile Produktivsoftware galten. So gab er Osada und Zap dann wieder an "die Community" weiter, die als quasi erste Amtshandlung mit Mikes Segen Osada nach Zap mergete, in dem Zuge auch auf Zap ActivityPub standardmäßig aktivierte und Osada kurzerhand einstellte.
2020 ging es dann weiter. Zap war damals State of the Art. Zot6 war so stabil, daß es nach Hubzilla zurückportiert wurde. Zap war jetzt quasi der modernere kleine Bruder von Hubzilla, der sich etwas eleganter bediente und einen nicht mit Features erschlug. Nur war Zap immer noch obskurer als Hubzilla, Hubzilla war obskurer als Friendica, und Friendica war selbst sehr obskur, weil für keins der drei wirklich Werbung gemacht wurde. Zap war weiterhin sonst nur auf Hubzilla bekannt und Hubzilla sonst nur auf Friendica.
Und Mike bastelte an Zot8, das nochmals besser werden sollte. Dafür brauchte er aber Software zum Experimentieren. Und so entstanden drei neue Forks in so kurzer Folge, daß heute nicht mehr bekannt ist, was jetzt wovon geforkt wurde, nur daß irgendwas von Zap geforkt worden ist. Im einzelnen waren das schon wieder ein neues Osada, ein neues Mistpark und eine neue Redmatrix.
Warum drei?
Es ging das Gerücht um, das seien verschiedene Stabilitätsstufen. Redmatrix 2020 sei experimentell mit wie früher bei Zap standardmäßig deaktiviertem ActivityPub, das damit der Entwicklung von Zot8 nicht im Wege stehe. Osada sei auch experimentell, aber wie früher schon bei Osada mit standardmäßig aktiviertem ActivityPub, um zu gucken, wie die Weiterentwicklungen von Zot8 sich mit ActivityPub vertragen. Mistpark 2020 wiederum sei "halbstabil" wie Debian testing, also stabiler als Osada und eher für den Produktiveinsatz geeignet, aber aktueller als Zap.
Zap sei also für die, die etwas neueres als Hubzilla haben wollten und auf die Zusatzfeatures von Hubzilla verzichten konnten. Misty sei für die, die etwas noch aktuelleres als Zap haben wollten, also das neueste Zeug noch früher, und die etwaige Instabilitäten in Kauf zu nehmen bereit waren. Osada sei für die, die unbedingt bleeding-edge wollten, instabil oder nicht. Und Redmatrix 2020 sei eh nur für Mike.
In Wahrheit waren Osada, Misty und Redmatrix 2020 bis auf das Branding völlig identisch und quasi Soft-Forks. Alle Commits wurden gleichermaßen und fast gleichzeitig in alle drei eingepflegt.
Warum?
Weil Mike der Markenfetischismus im Fediverse auf den Keks ging. Es gab Leute, die bildeten sich ein, die Software, die sie nutzten, sei die beste, einfach, weil sie Fans der Softwaremarke waren. Ganz besonders gab es die natürlich auf Mastodon, aber auch sonst. Genau diese Leute wollte er trollen, indem er drei bis auf den Namen und das Logo völlig identische Serveranwendungen pflegte. Misty z. B. konnte überhaupt nicht "die beste Fediverse-Serversoftware" sein, egal, wer sich das einbildete, wenn Osada und Redmatrix bis auf die Marke völlig baugleich waren.
Anfang 2021 kam dann Roadhouse dazu. Das Abenteuer Zot8 war im Grunde vorbei, bevor Zot8 stabil war. Denn Zot11 sollte noch besser werden. Vor allem sollte Zot11 von allen Zot-Versionen die beste Kompatibilität mit ActivityPub bekommen. Blöderweise konnte Mike aber Zot11 nicht auf Osada, Misty und Redmatrix entwickeln. Zot11 sollte nämlich zu allen Vorgängern so inkompatibel werden, daß es letztlich nicht mehr Zot heißen sollte. Aber es gab Leute, die Osada, Misty oder Redmatrix produktiv nutzten.
Also mußte Mike von einem von den dreien Roadhouse forken. War ihm aber egal, weil er damit die Leute mit noch einer weiteren Marke trollen konnte. Wohlgemerkt, effektiv hatte er sogar Zap noch an der Backe, weil es in der Community dann wohl doch zuwenig Interesse an der Weiterentwicklung gab.
Nomad, eigentlich ja Zot11, wurde zum Erfolg. Und das Erfolgsrezept lag auch darin, zusätzlich Support für Hubzillas Zot6 einzubauen, über den Roadhouse auch mit Osada, Misty und Redmatrix kommunizieren konnte. Ansonsten waren von den praktischen Features her Zap, Osada, Misty, Redmatrix und Roadhouse identisch und von der Benutzeroberfläche her auch beinahe. Es machte in der Praxis keinen großen Unterschied, welches man nutzte. Außerhalb waren sie eh, wenn überhaupt, nur auf Hubzilla bekannt. Das heißt, Roadhouse war beinahe komplett unbekannt, weil da endgültig nur Mike drüber redete.
Daß es (streams) gibt, obwohl Roadhouse doch gut war, hatte andere Gründe.
Grund 1: Mike fand einen neuen Weg, die Markenfetischisten zu trollen. Nämlich mit Software, die gar keinen Namen und gar keine Markenidentität hat. Also nahm Mike dem neuen Roadhouse-Fork von Ende 2021 den Namen und sogar den fediverseinternen festen Identifikator weg. Letzteren kann man entweder händisch ausfüllen, oder (streams) übernimmt ihn vom Instanznamen. Alleine das wäre mit einem "Debranding" von Roadhouse nicht getan gewesen, weil weiter alle von "Roadhouse" gesprochen hätten.
Grund 2: Dieses ständige Wetteifern, welche Software auf The Federation, Fediverse Observer, der FediDB usw. jetzt am populärsten ist und am meisten genutzt wird, ging ihm inzwischen auch auf dem Zeiger. Ein weiteres "Feature" von (streams) ist, daß Mike neben dem Namen und der Markenidentität auch nodeinfo praktisch komplett entfernt hat. (streams) sendet überhaupt keine Statistiken und hält sich von allen Instanzlisten-Websites fern. Und das ist so gewollt.
Grund 3: Zusätzlich wollte Mike es der Free-Software- und Open-Source-Community leichter machen. Da kloppt man sich ja bekanntlich darum, welche Lizenzen wirklich frei sind und welche nicht. Also hat Mike (streams), dessen sämtliche Vorgänger unter der MIT-Lizenz stehen, in die Public Domain gestellt. Freier als das geht's nun wirklich nicht mehr. Gleichzeitig wollte Mike diejenigen ärgern, die vielleicht vorhaben könnten, aus (streams) proprietäre, kommerzielle Closed-Source-Software zu machen. Die ganzen Apps sind nämlich durchaus schon mal Fremdcode und stehen unter eigenen Lizenzen. Und die sind untereinander inkompatibel.
(streams) sollte stabil werden und wurde stabil. Im Grunde war Mikes Plan, (streams) zu der Fediverse-Software der Zukunft zu machen. So hat er am 31.12.2022 offiziell Zap, Osada, Misty, Redmatrix und Roadhouse eingestellt. Das war aber kein Problem, denn zwischen den fünfen konnten Admins durch einfaches Rebasen nicht nur crossgraden, sondern auch zu (streams) upgraden.
Jetzt gab es nur noch Friendica, Hubzilla und (streams), wovon Mike nur noch (streams) betreute.
Dann kam ja silverpill auf Mike zu mit der Idee der nomadischen Identität über ActivityPub. Mike war interessiert. silverpill trieb das ziemlich voran inklusive dem einen oder anderen neuen FEP, darunter auch FEP-ef61, das in ActivityPub dezentrale Identitäten einführen sollte. Zot hat so etwas, Nomad natürlich auch, aber anders, und ActivityPub hatte das natürlich nicht.
Diese dezentralen Identitäten hat Mike auch in (streams) eingebaut. Langfristig sollte es ja möglich sein, zwischen verschiedenen Serveranwendungen zu klonen, so auch zwischen (streams) und Mitra. Zumindest aber sollten sie voneinander die dezentralen Identitäten als ebensolche verstehen. So sollte (streams) geklonte Mitra-Identitäten als solche erkennen, und Mitra sollte geklonte (streams)-Kanäle als solche erkennen.
Unter Laborbedingungen in Mikes nomadic-Zweig funktionierten die. Also mergete Mike im Juni 2024 den nomadic-Zweig in den dev-Zweig, den allgemeinen Entwicklungszweig. Auch der lief nur unter Laborbedingungen, weil (im Gegensatz zu Hubzilla, wo zwei öffentliche Produktivhubs Entwicklerversionen fahren) niemand außer Mike den dev-Zweig von (streams) produktiv fuhr.
Im Juli 2024 mergete Mike dann den dev-Zweig in den release-Zweig, um die neuesten Weiterentwicklungen an die produktiv gefahrenen, stabilen Server auszurollen. Da war allerdings Schluß mit Laborbedingungen. Jetzt mußten sich FEP-ef61 und die DIDs unter täglichen und breitgefächerten Realbedingungen beweisen.
Genau das taten sie nicht. Erst jetzt stellte sich heraus, daß (streams) mit den vielen Identitäten nicht klarkam. Es föderierte nicht mehr über ActivityPub. Es föderierte nicht mehr mit Hubzilla. Es föderierte nicht mal mehr mit sich selbst. Es konnte sich mit nichts mehr vernünftig verbinden.
Mike brauchte eine Weile, um überhaupt festzustellen, daß der Verursacher dieser Misere ein Identitätenchaos war. Das konnte er aber nicht auf (streams) selbst beheben. Hilfe hatte er auch keine. Die (streams)-Community war so winzig, da gab es niemanden, der ihm hätte helfen können. Der einzige, der die Fähigkeit gehabt hätte, hatte keine Zeit. Und der einzige, der Zeit und Bock hatte, hatte vom Coden keine Ahnung.
So mußte Mike sich erstmal einen Überblick verschaffen. Im August, also dem Monat nach dem Crash, als der Crash noch nicht behoben war, forkte er das streams-Repository und schuf Forte. Da wiederum riß er alles raus, was nicht ActivityPub war, also die Unterstützung sowohl von Nomad als auch von Zot6, um einen freien, ungehinderten Blick auf ActivityPub zu haben.
Inzwischen hatte er auch zwei andere Sachen gelernt: Software, die keinen Namen hat, interessiert keinen. Das verwirrt die Leute eher. Also bekam Forte wieder einen Namen. Die Public Domain brachte auch nichts. Also kam Forte wieder unter die MIT-Lizenz. Und Fediverse-Software, die überhaupt keine nodeinfo hat, ist praktisch unsichtbar. Also bekam Forte wieder nodeinfo, zunächst aber, ohne brauchbare Zahlen zu versenden. So konnte Forte zumindest vom Fediverse Observer und später vom FediIndex gelistet werden.
Forte half ihm, die ID-Misere zu entwirren, zu entflechten und zu lösen. Das reichte er dann auch nach (streams) weiter, das allmählich wieder funktionierte. Allerdings brannte er sich in dem August derart aus, daß er zum 31.8.2024 offiziell sowohl das streams-Repository als auch Forte zur Übernahme anbot und seinen Ruhestand ankündigte.
Dieses Mal fand eine Übernahme gleich gar nicht statt. Wie gesagt, in der (streams)-Community gab es niemanden, der sowohl die Zeit als auch das Know-how hatte, um auch nur Mike zu helfen, geschweige denn, eine Rolle wie Tobias oder Michael oder Mario anzunehmen.
Außerhalb von (streams) war (streams) selbst sogar auf Hubzilla kaum bekannt. Forte war sogar auf Hubzilla noch unbekannter, zumal es noch eine obskure, nichtöffentliche Bastelbude war, bis Mike im September 2024 die erste "offizielle" Entwicklerversion von Forte (und damit Forte selbst) veröffentlichte.
Und außerhalb von Hubzilla? Mike war es so leid, daß Mastodon als alternativlose Referenzimplementation des Fediverse angesehen wurde, daß er um 2023 anfing, Werbung für (streams) zu machen. Das erste Mal überhaupt, daß Mike von "wenn du es baust, werden sie kommen" abkam (es kam ja keiner) und irgendwas bewarb. Nur wußte Mike nicht, wie man zu Mastodon-Leuten spricht; ehrlich gesagt, das weiß auch auf Friendica und Hubzilla kaum jemand.
Oft genug ging aus Mikes Posts nicht mal hervor, daß er über ein konkretes Fediverse-Produkt sprach, und schon gar nicht, über welches. Wie auch, sprach er doch von etwas Namenlosem. Das heißt, auch er fing langsam an, den Namen des Repository zu verwenden. Aber er machte nicht unbedingt wirklich glasklar, daß er von etwas sprach, das jetzt in diesem Augenblick im Fediverse existierte. Schon gar nicht erwähnte er, daß es auch mit Mastodon verbunden ist, denn kaum jemand außerhalb von Mastodon weiß, daß Mastodon-Nutzer das nicht unbedingt automatisch verstehen.
Stand Mitte September 2024 hatte (streams) keine 100 aktiven Nutzer und Forte außer Mike gar keine. Traurigerweise hatte (streams) damals mehr öffentliche Server als heute, derweil Forte anderthalb Jahre gebraucht hat, um auch nur einen hervorzubringen. Wo sollen da Entwickler herkommen?
Mike hat übrigens nicht vor, (streams) einzustellen. Er und nicht nur er sagt, (streams) hat weiterhin seine Existenzberechtigung, und zwar als moderne Fediverse-Software, die von ActivityPub unabhängig ist. Er und nicht nur er sieht den ActivityPub-Schalter als eine Art letztes Bollwerk gegen Mastodon an und das einzige, das auf Kanalebene funktioniert, also nicht nur serverweit.
So, nun noch das Wort zu Smartphone-Apps.
Von Mike selbst war da nie etwas zu erwarten. Fediverse-Apps sind reine Frontend-Sachen. Und wir sollten inzwischen wissen, daß Mike nicht mal Web-UIs kann. Hubzilla ist für seine Oberfläche berüchtigt. Es ist doch erst schick geworden, als Saiwal mit seinen Utsukta-Themes anfing.
Außerdem hatte Mike immer schon genügend mit Webentwicklung zu tun. Da konnte man von ihm nicht auch noch erwarten, eine Smartphone-App zu entwickeln. Besser gesagt, zwei Smartphone-Apps, weil die iOS-App wahrscheinlich separat hätte entwickelt werden müssen. Mike wäre ja auch keiner gewesen, der in einer Smartphone-App nur das nötigste an Features eingebaut hätte. Wenn, dann alles. Er hätte also neben der Serversoftware zwei ziemliche Monster-Apps entwickeln und pflegen müssen.
Apps von Drittentwicklern?
Guck dir mal an, wie lange es gedauert hat, bis es von RaccoonForFriendica einen öffentlich verfügbaren Android-Release gab. Für iOS ist es meines Wissens bis heute nur über TestDrive verfügbar, aber nicht im App Store. Und selbst auf Android ist es noch nicht so stabil und fully featured, daß man es als Daily Driver nutzen könnte.
Für Hubzilla gab es mal Nomad für Android. Das wird seit gut sechs Jahren nicht mehr weiterentwickelt. Unter aktuellen Android-Versionen läuft es inzwischen gar nicht mehr. Und auch das ist nur ein Wrapper für die Weboberfläche, also ein glorifizierter Webbrowser. Ansonsten gibt's nur eine Minimalst-App von Mario, mit der er mal versuchsweise getestet hat, ob man von Android aus nach Hubzilla posten kann. Das ist absolut das einzige, was die App überhaupt kann.
Hubzilla hat eine Client API. Ob die aber funktioniert, ist weitestgehend unbekannt, weil noch nie jemand versucht hat, dagegen eine hinreichend mit Features ausgestattete App zu bauen. Dasselbe dürfte für (streams) und Forte gelten, für die es überhaupt noch nie irgendwelche Apps gegeben hat. Alle drei setzen statt dessen auf den Einsatz als PWA, nur daß da draußen keine Sau weiß, daß es das überhaupt gibt, geschweige denn, wie man das einrichtet.
Auf Drittentwickler kann man hier erst recht nicht hoffen. Von den Leuten im Fediverse, die Smartphone-Apps entwickeln können, kennt genau niemand Hubzilla, geschweige denn (streams) oder Forte. Selbst wenn sie Hubzilla kennenlernen würden, hätten sie keinen Bock, dafür eine App zu entwickeln. Lohnt sich nicht, weil nutzt keiner. Es lohnt sich viel mehr, die drölfzigtausendste reine Mastodon-App fürs iPhone zu bauen. Das heißt, mindestens die Hälfte von denen weiß doch sowieso nicht, was es außer Mastodon sonst noch so im Fediverse gibt.
Auf Hubzilla selbst gibt's nicht einen Mobilentwickler. Auf (streams) und Forte dürfte es niemanden geben, der überhaupt wirklich irgendwas entwickeln kann, nicht mal Webanwendungen (sonst hätte Mike Hilfe), Smartphone-Apps schon gar nicht.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendica #RedMatrix #Hubzilla #Osada #Zap #Roadhouse #Streams #(streams) #Forte -
@Kristian Na ja, Friendica war ja ausgereift. Zumindest soweit ausgereift, wie Friendica selbst und das DFRN-Protokoll es zuließen. Smartphone-Apps gab es nicht, weil man damals, 2010/2011, Smartphone-Apps für Sachen, die es auch als Websites gab, noch als Gimmicks ansah und noch nicht als lebensnotwendig. Das war, bevor die Leute gewisse Websites mehr über dedizierte Apps nutzten als über die Websites selbst.
Nur: Eine Weiterentwicklung war zwingend notwendig. Und die ging nicht mit Friendica, wie es war, denn die ging auch nicht mit DFRN.
Der Auslöser: 2011 waren binnen kurzer Zeit mehrere größere Friendica-Nodes von jetzt auf sofort ohne Ankündigung verschwunden. Einfach so weg. Friendica war durch das Verschwinden einiger weniger, aber jeweils sehr großer öffentlicher Nodes auf die Hälfte seiner Größe geschrumpft. Die andere Hälfte der Nutzer hatte alles verloren ohne die Chance, irgendwas zu retten. Die konnten wieder ganz neu bei null anfangen.
Das beste, was Mike an Friendica selbst machen konnte, war, eine Export- und Importfunktion einzubauen. Damit konnte man Backups des eigenen Konto machen. Das half aber nur, wenn man entweder brav ein tägliches Backup machte oder die Schließung eines Node vorher angekündigt wurde. Noch einmal: Genau das war 2011 nicht passiert. Die Nodes waren einfach futsch. Da hilft dir auch eine Backup-Funktion nicht, wenn du nicht laufend regelmäßig Backups machst.
Mike sah nur eine mögliche wirkliche Lösung. Und das war, indem deine Identität nicht bombenfest an einen Server gebunden ist, sondern simultan gleichzeitig als identische Klone auf mehreren unabhängigen Servern existieren kann. Wenn davon mal einer ausfällt, egal, die anderen laufen ja noch, also läuft deine Identität noch.
Problem: Mit DFRN ging das nicht umzusetzen. Es brauchte ein ganz neues Protokoll. Auch deshalb, weil Mike noch andere Verbesserungen im Kopf hatte wie ein nochmals deutlich aufgebohrtes Berechtigungssystem. Auch das ging mit DFRN so nicht und brauchte ein neues Protokoll. So entstand Zot.
Zum einen hieß ein neues Protokoll aber auch, wo auch immer das eingebaut werden soll, muß das komplette Backend ausgetauscht und neu geschrieben werden. Und große Teile des Frontend gleich mit. Das konnte Mike aber nicht auf Friendica im laufenden Betrieb machen. Friendica hätte unmöglich seine Grundfunktionalität gleichzeitig auf DFRN und auf Zot betreiben können. Und ein Protokollaustausch hätte bedeutet, daß Nodes, die die neue Friendica-Version mit Zot fahren, sich nicht mehr nativ hätten verbinden können mit Nodes, die alte Versionen mit DFRN fahren. Die wären zueinander inkompatibel gewesen.
Mike hatte als neue Entwicklungsplattform ja gerade das neue Red, das ein Fork seiner bisherigen "geheimen" Entwicklungsplattform Free-Friendika war. Das war ebenso "geheim", das konnte er also entsprechend umbauen.
Mike hätte aber niemals gleichzeitig Red komplett umbauen und Friendica selbst auf Free-Friendika weiterpflegen und die Weiterentwicklungen von Free-Friendika nach Friendica selbst bringen können. Und die einzige Alternative zum Umbau von Red auf Zot war, wieder solche Massencrashs wie 2011 mit exakt denselben Auswirkungen zu haben, ohne irgendwas tun zu können.
Also hat Mike sich auf Red konzentriert (dessen Umbau ja alleine schon länger dauern sollte als die Entwicklung von Friendica) und Friendica in die Hände von Tobias und Michael gegeben, die es seitdem nach ihren Vorstellungen weiterentwickeln. Die beiden waren ja meines Wissens sowieso schon Co-Entwickler von Friendica. Das hat Mike ja längst nicht mehr alles alleine gemacht.
Bei Red war das wieder anders. Das machte Mike ganz alleine. Das mußte er ja erstmal aufbauen. Und selbst als es fertig war, wurde es kaum angenommen. Es war zwar kein Geheimprojekt mehr, nachdem es sich von Friendica gelöst hatte. Aber es wurde kaum angenommen.
Auch als es umbenannt wurde in Red Matrix, was es leichter machte, es zu googlen, wurde es nicht angenommen. Die Friendica-Nutzer nahmen es wahr als Friendica mit nomadischer Identität. Was nomadische Identität ist, verstanden sie gar nicht. Selbst wenn doch: Die meisten von ihnen hatten inzwischen ihre eigenen privaten Einzelnutzer-Nodes.
So sahen sie in der Red Matrix gegenüber Friendica keine Vorteile, also warum umsteigen? Mal ganz davon abgesehen, daß Friendica und die Red Matrix nur über das diaspora*-Protokoll oder OStatus kommunizieren konnten. Die einzigen, die wechselten, dürften die gewesen sein, die eh immer das neueste, heißeste Zeug ausprobieren wollten.
Außerhalb von Friendica wußte eh keine Sau, daß die Red Matrix existierte. Herzlich wenige Leute wußten ja überhaupt auch nur, daß Friendica existierte. Mikes "Wenn du es baust, werden sie kommen" funktionierte damals schon nicht. Kleckerweise kamen noch neue Leute nach Friendica. Aber kaum einer ging von Friendica auf die Red Matrix, und absolut niemand ging von null auf die Red Matrix.
Interessant wurde die Red Matrix eigentlich erst 2015, als sie zu Hubzilla aufgebohrt wurde, also auf einmal Sachen konnte, die Friendica nicht konnte, die aber vielleicht nützlich sein konnten. Damit konnte Hubzilla auch für ganz andere Sachen eingesetzt werden als Friendica, also nicht nur als Facebook-Ersatz oder Blog.
Aber wenn Mario schon Anfang 2015 das noch brandneue Hubzilla übernahm, was ja so auf der offiziellen Website steht (nach meinen Informationen war es erst 2018), dann war es ein Wunder, daß Mike überhaupt jemanden fand, der übernehmen würde, der also schon seit Red-Matrix-Zeiten dabei war. Aber Mike hat ja an der Weiterentwicklung von Hubzilla noch weiter aktiv mitgewirkt, nur eben nicht als Projektleiter.
Hubzilla selbst wurde ja erst ab Ende 2015 interessant, als es seinen ersten stabilen Release hatte. Und auch Hubzillas Existenz war eigentlich nur auf Friendica bekannt. Selbst heute noch sind die allermeisten Hubzilla-Nutzer Friendica-Veteranen. Direkt von Mastodon nach Hubzilla ist kaum einer gekommen, von null nach Hubzilla schon gar nicht.
Selbst da war Mike keiner, der Sachen so läßt, wie sie sind, und sie nur noch weiter poliert. Wenn es etwas zu verbessern gibt, dann macht er das auch. Und wenn das nicht auf existierender Software im laufenden Produktivbetrieb geht, dann forkt er eben, und dann nimmt er sich weit mehr Zeit für seinen Fork als für das, was er vorher gemacht hatte. Und das ist auch gut so. Ansonsten hätten wir heute noch nur Friendica und immer noch keine Lösung für das Problem, daß die Leute alles verlieren, wenn mal wieder ein großer Node verschwindet.
Jetzt wollte Mike Zot weiterentwickeln, wohl auch deshalb, weil Zot, wie es damals war, nicht gut mit ActivityPub zusammenspielte. Aber potentiell kompatibilitätsbrechend. In einem eigenen zusätzlichen Branch von Hubzilla wäre das nicht gegangen, schon deshalb, weil Hubzilla für solche Experimente schlicht und ergreifend zu groß war.
Also hat Mike 2018 Osada von Hubzilla abgeforkt und alles rausgerissen, was im Weg war. Artikel, Karten, Wikis, Webpages, alle Verbindungsmöglichkeiten außer Zot, ActivityPub und RSS/Atom, alles raus.
Weil dann abzusehen war, daß nomadisches Zot6 (zumindest vorerst) mit ActivityPub überhaupt nicht mehr funktionieren würde, brauchte Mike zwei Projekte: Osada behielt ActivityPub, wurde aber nichtnomadisch. Zusätzlich forkte er Zap von Osada, ließ es nomadisch, entfernte aber ActivityPub.
Jetzt konnte Mike endgültig nicht gleichzeitig Zot6 entwickeln und Osada entwickeln und Zap entwickeln und Hubzilla weiterpflegen. Auch dieses Mal half ihm bei den Neuentwicklungen niemand. Also überließ er Hubzilla gänzlich Mario.
Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.
Anfang 2019 fand er einen Weg, auch nomadisches Zot6 mit ActivityPub kompatibel zu machen. Abgesehen davon war die Idee, einen nomadischen Zap-Kanal über einen nichtnomadischen Osada-Kanal mit dem Fediverse zu verbinden, sowieso kompletter Blödsinn und technisch in der Praxis kaum realisierbar, selbst mit Kanalquellen nicht. Also stellte Mike Osada ein, forkte von Zap ein ganz neues Osada und baute da ActivityPub-Support ein. Noch war nomadisches Zot6 + ActivityPub ja noch experimentell, deswegen hat er es nicht in Zap eingebaut.
Dann aber wurden Osada und Zap stabil und bekamen sogar einen 1.0-Release. Inzwischen gab es Leute, die Osada oder Zap produktiv nutzten. Die kamen alle von Hubzilla, denn nur da wußte man, daß es Osada und Zap gab. Nicht mal auf Friendica wußte das jemand, im übrigen Fediverse erst recht nicht und außerhalb des Fediverse schon gar nicht.
So baute Mike dann Osadas ActivityPub-Support auch in Zap ein, schaltete ihn aber standardmäßig auf Serverebene ab, auf Kanalebene sowieso. Das führte dazu, daß Osada und Zap bis auf das Branding und die Standardeinstellungen völlig identisch waren. Es brauchte gar nicht mehr beide. Mike ließ das aber so.
Irgendwie gab es wohl genug Osada- und Zap-Anwender, daß Mike jemanden fand, der beides weiterpflegen wollte. Denn Mike hatte wieder neue Weiterentwicklungen im Sinne, die er aber nicht mehr auf Osada und Zap machen konnte, weil die jetzt beide als stabile Produktivsoftware galten. So gab er Osada und Zap dann wieder an "die Community" weiter, die als quasi erste Amtshandlung mit Mikes Segen Osada nach Zap mergete, in dem Zuge auch auf Zap ActivityPub standardmäßig aktivierte und Osada kurzerhand einstellte.
2020 ging es dann weiter. Zap war damals State of the Art. Zot6 war so stabil, daß es nach Hubzilla zurückportiert wurde. Zap war jetzt quasi der modernere kleine Bruder von Hubzilla, der sich etwas eleganter bediente und einen nicht mit Features erschlug. Nur war Zap immer noch obskurer als Hubzilla, Hubzilla war obskurer als Friendica, und Friendica war selbst sehr obskur, weil für keins der drei wirklich Werbung gemacht wurde. Zap war weiterhin sonst nur auf Hubzilla bekannt und Hubzilla sonst nur auf Friendica.
Und Mike bastelte an Zot8, das nochmals besser werden sollte. Dafür brauchte er aber Software zum Experimentieren. Und so entstanden drei neue Forks in so kurzer Folge, daß heute nicht mehr bekannt ist, was jetzt wovon geforkt wurde, nur daß irgendwas von Zap geforkt worden ist. Im einzelnen waren das schon wieder ein neues Osada, ein neues Mistpark und eine neue Redmatrix.
Warum drei?
Es ging das Gerücht um, das seien verschiedene Stabilitätsstufen. Redmatrix 2020 sei experimentell mit wie früher bei Zap standardmäßig deaktiviertem ActivityPub, das damit der Entwicklung von Zot8 nicht im Wege stehe. Osada sei auch experimentell, aber wie früher schon bei Osada mit standardmäßig aktiviertem ActivityPub, um zu gucken, wie die Weiterentwicklungen von Zot8 sich mit ActivityPub vertragen. Mistpark 2020 wiederum sei "halbstabil" wie Debian testing, also stabiler als Osada und eher für den Produktiveinsatz geeignet, aber aktueller als Zap.
Zap sei also für die, die etwas neueres als Hubzilla haben wollten und auf die Zusatzfeatures von Hubzilla verzichten konnten. Misty sei für die, die etwas noch aktuelleres als Zap haben wollten, also das neueste Zeug noch früher, und die etwaige Instabilitäten in Kauf zu nehmen bereit waren. Osada sei für die, die unbedingt bleeding-edge wollten, instabil oder nicht. Und Redmatrix 2020 sei eh nur für Mike.
In Wahrheit waren Osada, Misty und Redmatrix 2020 bis auf das Branding völlig identisch und quasi Soft-Forks. Alle Commits wurden gleichermaßen und fast gleichzeitig in alle drei eingepflegt.
Warum?
Weil Mike der Markenfetischismus im Fediverse auf den Keks ging. Es gab Leute, die bildeten sich ein, die Software, die sie nutzten, sei die beste, einfach, weil sie Fans der Softwaremarke waren. Ganz besonders gab es die natürlich auf Mastodon, aber auch sonst. Genau diese Leute wollte er trollen, indem er drei bis auf den Namen und das Logo völlig identische Serveranwendungen pflegte. Misty z. B. konnte überhaupt nicht "die beste Fediverse-Serversoftware" sein, egal, wer sich das einbildete, wenn Osada und Redmatrix bis auf die Marke völlig baugleich waren.
Anfang 2021 kam dann Roadhouse dazu. Das Abenteuer Zot8 war im Grunde vorbei, bevor Zot8 stabil war. Denn Zot11 sollte noch besser werden. Vor allem sollte Zot11 von allen Zot-Versionen die beste Kompatibilität mit ActivityPub bekommen. Blöderweise konnte Mike aber Zot11 nicht auf Osada, Misty und Redmatrix entwickeln. Zot11 sollte nämlich zu allen Vorgängern so inkompatibel werden, daß es letztlich nicht mehr Zot heißen sollte. Aber es gab Leute, die Osada, Misty oder Redmatrix produktiv nutzten.
Also mußte Mike von einem von den dreien Roadhouse forken. War ihm aber egal, weil er damit die Leute mit noch einer weiteren Marke trollen konnte. Wohlgemerkt, effektiv hatte er sogar Zap noch an der Backe, weil es in der Community dann wohl doch zuwenig Interesse an der Weiterentwicklung gab.
Nomad, eigentlich ja Zot11, wurde zum Erfolg. Und das Erfolgsrezept lag auch darin, zusätzlich Support für Hubzillas Zot6 einzubauen, über den Roadhouse auch mit Osada, Misty und Redmatrix kommunizieren konnte. Ansonsten waren von den praktischen Features her Zap, Osada, Misty, Redmatrix und Roadhouse identisch und von der Benutzeroberfläche her auch beinahe. Es machte in der Praxis keinen großen Unterschied, welches man nutzte. Außerhalb waren sie eh, wenn überhaupt, nur auf Hubzilla bekannt. Das heißt, Roadhouse war beinahe komplett unbekannt, weil da endgültig nur Mike drüber redete.
Daß es (streams) gibt, obwohl Roadhouse doch gut war, hatte andere Gründe.
Grund 1: Mike fand einen neuen Weg, die Markenfetischisten zu trollen. Nämlich mit Software, die gar keinen Namen und gar keine Markenidentität hat. Also nahm Mike dem neuen Roadhouse-Fork von Ende 2021 den Namen und sogar den fediverseinternen festen Identifikator weg. Letzteren kann man entweder händisch ausfüllen, oder (streams) übernimmt ihn vom Instanznamen. Alleine das wäre mit einem "Debranding" von Roadhouse nicht getan gewesen, weil weiter alle von "Roadhouse" gesprochen hätten.
Grund 2: Dieses ständige Wetteifern, welche Software auf The Federation, Fediverse Observer, der FediDB usw. jetzt am populärsten ist und am meisten genutzt wird, ging ihm inzwischen auch auf dem Zeiger. Ein weiteres "Feature" von (streams) ist, daß Mike neben dem Namen und der Markenidentität auch nodeinfo praktisch komplett entfernt hat. (streams) sendet überhaupt keine Statistiken und hält sich von allen Instanzlisten-Websites fern. Und das ist so gewollt.
Grund 3: Zusätzlich wollte Mike es der Free-Software- und Open-Source-Community leichter machen. Da kloppt man sich ja bekanntlich darum, welche Lizenzen wirklich frei sind und welche nicht. Also hat Mike (streams), dessen sämtliche Vorgänger unter der MIT-Lizenz stehen, in die Public Domain gestellt. Freier als das geht's nun wirklich nicht mehr. Gleichzeitig wollte Mike diejenigen ärgern, die vielleicht vorhaben könnten, aus (streams) proprietäre, kommerzielle Closed-Source-Software zu machen. Die ganzen Apps sind nämlich durchaus schon mal Fremdcode und stehen unter eigenen Lizenzen. Und die sind untereinander inkompatibel.
(streams) sollte stabil werden und wurde stabil. Im Grunde war Mikes Plan, (streams) zu der Fediverse-Software der Zukunft zu machen. So hat er am 31.12.2022 offiziell Zap, Osada, Misty, Redmatrix und Roadhouse eingestellt. Das war aber kein Problem, denn zwischen den fünfen konnten Admins durch einfaches Rebasen nicht nur crossgraden, sondern auch zu (streams) upgraden.
Jetzt gab es nur noch Friendica, Hubzilla und (streams), wovon Mike nur noch (streams) betreute.
Dann kam ja silverpill auf Mike zu mit der Idee der nomadischen Identität über ActivityPub. Mike war interessiert. silverpill trieb das ziemlich voran inklusive dem einen oder anderen neuen FEP, darunter auch FEP-ef61, das in ActivityPub dezentrale Identitäten einführen sollte. Zot hat so etwas, Nomad natürlich auch, aber anders, und ActivityPub hatte das natürlich nicht.
Diese dezentralen Identitäten hat Mike auch in (streams) eingebaut. Langfristig sollte es ja möglich sein, zwischen verschiedenen Serveranwendungen zu klonen, so auch zwischen (streams) und Mitra. Zumindest aber sollten sie voneinander die dezentralen Identitäten als ebensolche verstehen. So sollte (streams) geklonte Mitra-Identitäten als solche erkennen, und Mitra sollte geklonte (streams)-Kanäle als solche erkennen.
Unter Laborbedingungen in Mikes nomadic-Zweig funktionierten die. Also mergete Mike im Juni 2024 den nomadic-Zweig in den dev-Zweig, den allgemeinen Entwicklungszweig. Auch der lief nur unter Laborbedingungen, weil (im Gegensatz zu Hubzilla, wo zwei öffentliche Produktivhubs Entwicklerversionen fahren) niemand außer Mike den dev-Zweig von (streams) produktiv fuhr.
Im Juli 2024 mergete Mike dann den dev-Zweig in den release-Zweig, um die neuesten Weiterentwicklungen an die produktiv gefahrenen, stabilen Server auszurollen. Da war allerdings Schluß mit Laborbedingungen. Jetzt mußten sich FEP-ef61 und die DIDs unter täglichen und breitgefächerten Realbedingungen beweisen.
Genau das taten sie nicht. Erst jetzt stellte sich heraus, daß (streams) mit den vielen Identitäten nicht klarkam. Es föderierte nicht mehr über ActivityPub. Es föderierte nicht mehr mit Hubzilla. Es föderierte nicht mal mehr mit sich selbst. Es konnte sich mit nichts mehr vernünftig verbinden.
Mike brauchte eine Weile, um überhaupt festzustellen, daß der Verursacher dieser Misere ein Identitätenchaos war. Das konnte er aber nicht auf (streams) selbst beheben. Hilfe hatte er auch keine. Die (streams)-Community war so winzig, da gab es niemanden, der ihm hätte helfen können. Der einzige, der die Fähigkeit gehabt hätte, hatte keine Zeit. Und der einzige, der Zeit und Bock hatte, hatte vom Coden keine Ahnung.
So mußte Mike sich erstmal einen Überblick verschaffen. Im August, also dem Monat nach dem Crash, als der Crash noch nicht behoben war, forkte er das streams-Repository und schuf Forte. Da wiederum riß er alles raus, was nicht ActivityPub war, also die Unterstützung sowohl von Nomad als auch von Zot6, um einen freien, ungehinderten Blick auf ActivityPub zu haben.
Inzwischen hatte er auch zwei andere Sachen gelernt: Software, die keinen Namen hat, interessiert keinen. Das verwirrt die Leute eher. Also bekam Forte wieder einen Namen. Die Public Domain brachte auch nichts. Also kam Forte wieder unter die MIT-Lizenz. Und Fediverse-Software, die überhaupt keine nodeinfo hat, ist praktisch unsichtbar. Also bekam Forte wieder nodeinfo, zunächst aber, ohne brauchbare Zahlen zu versenden. So konnte Forte zumindest vom Fediverse Observer und später vom FediIndex gelistet werden.
Forte half ihm, die ID-Misere zu entwirren, zu entflechten und zu lösen. Das reichte er dann auch nach (streams) weiter, das allmählich wieder funktionierte. Allerdings brannte er sich in dem August derart aus, daß er zum 31.8.2024 offiziell sowohl das streams-Repository als auch Forte zur Übernahme anbot und seinen Ruhestand ankündigte.
Dieses Mal fand eine Übernahme gleich gar nicht statt. Wie gesagt, in der (streams)-Community gab es niemanden, der sowohl die Zeit als auch das Know-how hatte, um auch nur Mike zu helfen, geschweige denn, eine Rolle wie Tobias oder Michael oder Mario anzunehmen.
Außerhalb von (streams) war (streams) selbst sogar auf Hubzilla kaum bekannt. Forte war sogar auf Hubzilla noch unbekannter, zumal es noch eine obskure, nichtöffentliche Bastelbude war, bis Mike im September 2024 die erste "offizielle" Entwicklerversion von Forte (und damit Forte selbst) veröffentlichte.
Und außerhalb von Hubzilla? Mike war es so leid, daß Mastodon als alternativlose Referenzimplementation des Fediverse angesehen wurde, daß er um 2023 anfing, Werbung für (streams) zu machen. Das erste Mal überhaupt, daß Mike von "wenn du es baust, werden sie kommen" abkam (es kam ja keiner) und irgendwas bewarb. Nur wußte Mike nicht, wie man zu Mastodon-Leuten spricht; ehrlich gesagt, das weiß auch auf Friendica und Hubzilla kaum jemand.
Oft genug ging aus Mikes Posts nicht mal hervor, daß er über ein konkretes Fediverse-Produkt sprach, und schon gar nicht, über welches. Wie auch, sprach er doch von etwas Namenlosem. Das heißt, auch er fing langsam an, den Namen des Repository zu verwenden. Aber er machte nicht unbedingt wirklich glasklar, daß er von etwas sprach, das jetzt in diesem Augenblick im Fediverse existierte. Schon gar nicht erwähnte er, daß es auch mit Mastodon verbunden ist, denn kaum jemand außerhalb von Mastodon weiß, daß Mastodon-Nutzer das nicht unbedingt automatisch verstehen.
Stand Mitte September 2024 hatte (streams) keine 100 aktiven Nutzer und Forte außer Mike gar keine. Traurigerweise hatte (streams) damals mehr öffentliche Server als heute, derweil Forte anderthalb Jahre gebraucht hat, um auch nur einen hervorzubringen. Wo sollen da Entwickler herkommen?
Mike hat übrigens nicht vor, (streams) einzustellen. Er und nicht nur er sagt, (streams) hat weiterhin seine Existenzberechtigung, und zwar als moderne Fediverse-Software, die von ActivityPub unabhängig ist. Er und nicht nur er sieht den ActivityPub-Schalter als eine Art letztes Bollwerk gegen Mastodon an und das einzige, das auf Kanalebene funktioniert, also nicht nur serverweit.
So, nun noch das Wort zu Smartphone-Apps.
Von Mike selbst war da nie etwas zu erwarten. Fediverse-Apps sind reine Frontend-Sachen. Und wir sollten inzwischen wissen, daß Mike nicht mal Web-UIs kann. Hubzilla ist für seine Oberfläche berüchtigt. Es ist doch erst schick geworden, als Saiwal mit seinen Utsukta-Themes anfing.
Außerdem hatte Mike immer schon genügend mit Webentwicklung zu tun. Da konnte man von ihm nicht auch noch erwarten, eine Smartphone-App zu entwickeln. Besser gesagt, zwei Smartphone-Apps, weil die iOS-App wahrscheinlich separat hätte entwickelt werden müssen. Mike wäre ja auch keiner gewesen, der in einer Smartphone-App nur das nötigste an Features eingebaut hätte. Wenn, dann alles. Er hätte also neben der Serversoftware zwei ziemliche Monster-Apps entwickeln und pflegen müssen.
Apps von Drittentwicklern?
Guck dir mal an, wie lange es gedauert hat, bis es von RaccoonForFriendica einen öffentlich verfügbaren Android-Release gab. Für iOS ist es meines Wissens bis heute nur über TestDrive verfügbar, aber nicht im App Store. Und selbst auf Android ist es noch nicht so stabil und fully featured, daß man es als Daily Driver nutzen könnte.
Für Hubzilla gab es mal Nomad für Android. Das wird seit gut sechs Jahren nicht mehr weiterentwickelt. Unter aktuellen Android-Versionen läuft es inzwischen gar nicht mehr. Und auch das ist nur ein Wrapper für die Weboberfläche, also ein glorifizierter Webbrowser. Ansonsten gibt's nur eine Minimalst-App von Mario, mit der er mal versuchsweise getestet hat, ob man von Android aus nach Hubzilla posten kann. Das ist absolut das einzige, was die App überhaupt kann.
Hubzilla hat eine Client API. Ob die aber funktioniert, ist weitestgehend unbekannt, weil noch nie jemand versucht hat, dagegen eine hinreichend mit Features ausgestattete App zu bauen. Dasselbe dürfte für (streams) und Forte gelten, für die es überhaupt noch nie irgendwelche Apps gegeben hat. Alle drei setzen statt dessen auf den Einsatz als PWA, nur daß da draußen keine Sau weiß, daß es das überhaupt gibt, geschweige denn, wie man das einrichtet.
Auf Drittentwickler kann man hier erst recht nicht hoffen. Von den Leuten im Fediverse, die Smartphone-Apps entwickeln können, kennt genau niemand Hubzilla, geschweige denn (streams) oder Forte. Selbst wenn sie Hubzilla kennenlernen würden, hätten sie keinen Bock, dafür eine App zu entwickeln. Lohnt sich nicht, weil nutzt keiner. Es lohnt sich viel mehr, die drölfzigtausendste reine Mastodon-App fürs iPhone zu bauen. Das heißt, mindestens die Hälfte von denen weiß doch sowieso nicht, was es außer Mastodon sonst noch so im Fediverse gibt.
Auf Hubzilla selbst gibt's nicht einen Mobilentwickler. Auf (streams) und Forte dürfte es niemanden geben, der überhaupt wirklich irgendwas entwickeln kann, nicht mal Webanwendungen (sonst hätte Mike Hilfe), Smartphone-Apps schon gar nicht.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendica #RedMatrix #Hubzilla #Osada #Zap #Roadhouse #Streams #(streams) #Forte -
@Kristian Na ja, Friendica war ja ausgereift. Zumindest soweit ausgereift, wie Friendica selbst und das DFRN-Protokoll es zuließen. Smartphone-Apps gab es nicht, weil man damals, 2010/2011, Smartphone-Apps für Sachen, die es auch als Websites gab, noch als Gimmicks ansah und noch nicht als lebensnotwendig. Das war, bevor die Leute gewisse Websites mehr über dedizierte Apps nutzten als über die Websites selbst.
Nur: Eine Weiterentwicklung war zwingend notwendig. Und die ging nicht mit Friendica, wie es war, denn die ging auch nicht mit DFRN.
Der Auslöser: 2011 waren binnen kurzer Zeit mehrere größere Friendica-Nodes von jetzt auf sofort ohne Ankündigung verschwunden. Einfach so weg. Friendica war durch das Verschwinden einiger weniger, aber jeweils sehr großer öffentlicher Nodes auf die Hälfte seiner Größe geschrumpft. Die andere Hälfte der Nutzer hatte alles verloren ohne die Chance, irgendwas zu retten. Die konnten wieder ganz neu bei null anfangen.
Das beste, was Mike an Friendica selbst machen konnte, war, eine Export- und Importfunktion einzubauen. Damit konnte man Backups des eigenen Konto machen. Das half aber nur, wenn man entweder brav ein tägliches Backup machte oder die Schließung eines Node vorher angekündigt wurde. Noch einmal: Genau das war 2011 nicht passiert. Die Nodes waren einfach futsch. Da hilft dir auch eine Backup-Funktion nicht, wenn du nicht laufend regelmäßig Backups machst.
Mike sah nur eine mögliche wirkliche Lösung. Und das war, indem deine Identität nicht bombenfest an einen Server gebunden ist, sondern simultan gleichzeitig als identische Klone auf mehreren unabhängigen Servern existieren kann. Wenn davon mal einer ausfällt, egal, die anderen laufen ja noch, also läuft deine Identität noch.
Problem: Mit DFRN ging das nicht umzusetzen. Es brauchte ein ganz neues Protokoll. Auch deshalb, weil Mike noch andere Verbesserungen im Kopf hatte wie ein nochmals deutlich aufgebohrtes Berechtigungssystem. Auch das ging mit DFRN so nicht und brauchte ein neues Protokoll. So entstand Zot.
Zum einen hieß ein neues Protokoll aber auch, wo auch immer das eingebaut werden soll, muß das komplette Backend ausgetauscht und neu geschrieben werden. Und große Teile des Frontend gleich mit. Das konnte Mike aber nicht auf Friendica im laufenden Betrieb machen. Friendica hätte unmöglich seine Grundfunktionalität gleichzeitig auf DFRN und auf Zot betreiben können. Und ein Protokollaustausch hätte bedeutet, daß Nodes, die die neue Friendica-Version mit Zot fahren, sich nicht mehr nativ hätten verbinden können mit Nodes, die alte Versionen mit DFRN fahren. Die wären zueinander inkompatibel gewesen.
Mike hatte als neue Entwicklungsplattform ja gerade das neue Red, das ein Fork seiner bisherigen "geheimen" Entwicklungsplattform Free-Friendika war. Das war ebenso "geheim", das konnte er also entsprechend umbauen.
Mike hätte aber niemals gleichzeitig Red komplett umbauen und Friendica selbst auf Free-Friendika weiterpflegen und die Weiterentwicklungen von Free-Friendika nach Friendica selbst bringen können. Und die einzige Alternative zum Umbau von Red auf Zot war, wieder solche Massencrashs wie 2011 mit exakt denselben Auswirkungen zu haben, ohne irgendwas tun zu können.
Also hat Mike sich auf Red konzentriert (dessen Umbau ja alleine schon länger dauern sollte als die Entwicklung von Friendica) und Friendica in die Hände von Tobias und Michael gegeben, die es seitdem nach ihren Vorstellungen weiterentwickeln. Die beiden waren ja meines Wissens sowieso schon Co-Entwickler von Friendica. Das hat Mike ja längst nicht mehr alles alleine gemacht.
Bei Red war das wieder anders. Das machte Mike ganz alleine. Das mußte er ja erstmal aufbauen. Und selbst als es fertig war, wurde es kaum angenommen. Es war zwar kein Geheimprojekt mehr, nachdem es sich von Friendica gelöst hatte. Aber es wurde kaum angenommen.
Auch als es umbenannt wurde in Red Matrix, was es leichter machte, es zu googlen, wurde es nicht angenommen. Die Friendica-Nutzer nahmen es wahr als Friendica mit nomadischer Identität. Was nomadische Identität ist, verstanden sie gar nicht. Selbst wenn doch: Die meisten von ihnen hatten inzwischen ihre eigenen privaten Einzelnutzer-Nodes.
So sahen sie in der Red Matrix gegenüber Friendica keine Vorteile, also warum umsteigen? Mal ganz davon abgesehen, daß Friendica und die Red Matrix nur über das diaspora*-Protokoll oder OStatus kommunizieren konnten. Die einzigen, die wechselten, dürften die gewesen sein, die eh immer das neueste, heißeste Zeug ausprobieren wollten.
Außerhalb von Friendica wußte eh keine Sau, daß die Red Matrix existierte. Herzlich wenige Leute wußten ja überhaupt auch nur, daß Friendica existierte. Mikes "Wenn du es baust, werden sie kommen" funktionierte damals schon nicht. Kleckerweise kamen noch neue Leute nach Friendica. Aber kaum einer ging von Friendica auf die Red Matrix, und absolut niemand ging von null auf die Red Matrix.
Interessant wurde die Red Matrix eigentlich erst 2015, als sie zu Hubzilla aufgebohrt wurde, also auf einmal Sachen konnte, die Friendica nicht konnte, die aber vielleicht nützlich sein konnten. Damit konnte Hubzilla auch für ganz andere Sachen eingesetzt werden als Friendica, also nicht nur als Facebook-Ersatz oder Blog.
Aber wenn Mario schon Anfang 2015 das noch brandneue Hubzilla übernahm, was ja so auf der offiziellen Website steht (nach meinen Informationen war es erst 2018), dann war es ein Wunder, daß Mike überhaupt jemanden fand, der übernehmen würde, der also schon seit Red-Matrix-Zeiten dabei war. Aber Mike hat ja an der Weiterentwicklung von Hubzilla noch weiter aktiv mitgewirkt, nur eben nicht als Projektleiter.
Hubzilla selbst wurde ja erst ab Ende 2015 interessant, als es seinen ersten stabilen Release hatte. Und auch Hubzillas Existenz war eigentlich nur auf Friendica bekannt. Selbst heute noch sind die allermeisten Hubzilla-Nutzer Friendica-Veteranen. Direkt von Mastodon nach Hubzilla ist kaum einer gekommen, von null nach Hubzilla schon gar nicht.
Selbst da war Mike keiner, der Sachen so läßt, wie sie sind, und sie nur noch weiter poliert. Wenn es etwas zu verbessern gibt, dann macht er das auch. Und wenn das nicht auf existierender Software im laufenden Produktivbetrieb geht, dann forkt er eben, und dann nimmt er sich weit mehr Zeit für seinen Fork als für das, was er vorher gemacht hatte. Und das ist auch gut so. Ansonsten hätten wir heute noch nur Friendica und immer noch keine Lösung für das Problem, daß die Leute alles verlieren, wenn mal wieder ein großer Node verschwindet.
Jetzt wollte Mike Zot weiterentwickeln, wohl auch deshalb, weil Zot, wie es damals war, nicht gut mit ActivityPub zusammenspielte. Aber potentiell kompatibilitätsbrechend. In einem eigenen zusätzlichen Branch von Hubzilla wäre das nicht gegangen, schon deshalb, weil Hubzilla für solche Experimente schlicht und ergreifend zu groß war.
Also hat Mike 2018 Osada von Hubzilla abgeforkt und alles rausgerissen, was im Weg war. Artikel, Karten, Wikis, Webpages, alle Verbindungsmöglichkeiten außer Zot, ActivityPub und RSS/Atom, alles raus.
Weil dann abzusehen war, daß nomadisches Zot6 (zumindest vorerst) mit ActivityPub überhaupt nicht mehr funktionieren würde, brauchte Mike zwei Projekte: Osada behielt ActivityPub, wurde aber nichtnomadisch. Zusätzlich forkte er Zap von Osada, ließ es nomadisch, entfernte aber ActivityPub.
Jetzt konnte Mike endgültig nicht gleichzeitig Zot6 entwickeln und Osada entwickeln und Zap entwickeln und Hubzilla weiterpflegen. Auch dieses Mal half ihm bei den Neuentwicklungen niemand. Also überließ er Hubzilla gänzlich Mario.
Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.
Anfang 2019 fand er einen Weg, auch nomadisches Zot6 mit ActivityPub kompatibel zu machen. Abgesehen davon war die Idee, einen nomadischen Zap-Kanal über einen nichtnomadischen Osada-Kanal mit dem Fediverse zu verbinden, sowieso kompletter Blödsinn und technisch in der Praxis kaum realisierbar, selbst mit Kanalquellen nicht. Also stellte Mike Osada ein, forkte von Zap ein ganz neues Osada und baute da ActivityPub-Support ein. Noch war nomadisches Zot6 + ActivityPub ja noch experimentell, deswegen hat er es nicht in Zap eingebaut.
Dann aber wurden Osada und Zap stabil und bekamen sogar einen 1.0-Release. Inzwischen gab es Leute, die Osada oder Zap produktiv nutzten. Die kamen alle von Hubzilla, denn nur da wußte man, daß es Osada und Zap gab. Nicht mal auf Friendica wußte das jemand, im übrigen Fediverse erst recht nicht und außerhalb des Fediverse schon gar nicht.
So baute Mike dann Osadas ActivityPub-Support auch in Zap ein, schaltete ihn aber standardmäßig auf Serverebene ab, auf Kanalebene sowieso. Das führte dazu, daß Osada und Zap bis auf das Branding und die Standardeinstellungen völlig identisch waren. Es brauchte gar nicht mehr beide. Mike ließ das aber so.
Irgendwie gab es wohl genug Osada- und Zap-Anwender, daß Mike jemanden fand, der beides weiterpflegen wollte. Denn Mike hatte wieder neue Weiterentwicklungen im Sinne, die er aber nicht mehr auf Osada und Zap machen konnte, weil die jetzt beide als stabile Produktivsoftware galten. So gab er Osada und Zap dann wieder an "die Community" weiter, die als quasi erste Amtshandlung mit Mikes Segen Osada nach Zap mergete, in dem Zuge auch auf Zap ActivityPub standardmäßig aktivierte und Osada kurzerhand einstellte.
2020 ging es dann weiter. Zap war damals State of the Art. Zot6 war so stabil, daß es nach Hubzilla zurückportiert wurde. Zap war jetzt quasi der modernere kleine Bruder von Hubzilla, der sich etwas eleganter bediente und einen nicht mit Features erschlug. Nur war Zap immer noch obskurer als Hubzilla, Hubzilla war obskurer als Friendica, und Friendica war selbst sehr obskur, weil für keins der drei wirklich Werbung gemacht wurde. Zap war weiterhin sonst nur auf Hubzilla bekannt und Hubzilla sonst nur auf Friendica.
Und Mike bastelte an Zot8, das nochmals besser werden sollte. Dafür brauchte er aber Software zum Experimentieren. Und so entstanden drei neue Forks in so kurzer Folge, daß heute nicht mehr bekannt ist, was jetzt wovon geforkt wurde, nur daß irgendwas von Zap geforkt worden ist. Im einzelnen waren das schon wieder ein neues Osada, ein neues Mistpark und eine neue Redmatrix.
Warum drei?
Es ging das Gerücht um, das seien verschiedene Stabilitätsstufen. Redmatrix 2020 sei experimentell mit wie früher bei Zap standardmäßig deaktiviertem ActivityPub, das damit der Entwicklung von Zot8 nicht im Wege stehe. Osada sei auch experimentell, aber wie früher schon bei Osada mit standardmäßig aktiviertem ActivityPub, um zu gucken, wie die Weiterentwicklungen von Zot8 sich mit ActivityPub vertragen. Mistpark 2020 wiederum sei "halbstabil" wie Debian testing, also stabiler als Osada und eher für den Produktiveinsatz geeignet, aber aktueller als Zap.
Zap sei also für die, die etwas neueres als Hubzilla haben wollten und auf die Zusatzfeatures von Hubzilla verzichten konnten. Misty sei für die, die etwas noch aktuelleres als Zap haben wollten, also das neueste Zeug noch früher, und die etwaige Instabilitäten in Kauf zu nehmen bereit waren. Osada sei für die, die unbedingt bleeding-edge wollten, instabil oder nicht. Und Redmatrix 2020 sei eh nur für Mike.
In Wahrheit waren Osada, Misty und Redmatrix 2020 bis auf das Branding völlig identisch und quasi Soft-Forks. Alle Commits wurden gleichermaßen und fast gleichzeitig in alle drei eingepflegt.
Warum?
Weil Mike der Markenfetischismus im Fediverse auf den Keks ging. Es gab Leute, die bildeten sich ein, die Software, die sie nutzten, sei die beste, einfach, weil sie Fans der Softwaremarke waren. Ganz besonders gab es die natürlich auf Mastodon, aber auch sonst. Genau diese Leute wollte er trollen, indem er drei bis auf den Namen und das Logo völlig identische Serveranwendungen pflegte. Misty z. B. konnte überhaupt nicht "die beste Fediverse-Serversoftware" sein, egal, wer sich das einbildete, wenn Osada und Redmatrix bis auf die Marke völlig baugleich waren.
Anfang 2021 kam dann Roadhouse dazu. Das Abenteuer Zot8 war im Grunde vorbei, bevor Zot8 stabil war. Denn Zot11 sollte noch besser werden. Vor allem sollte Zot11 von allen Zot-Versionen die beste Kompatibilität mit ActivityPub bekommen. Blöderweise konnte Mike aber Zot11 nicht auf Osada, Misty und Redmatrix entwickeln. Zot11 sollte nämlich zu allen Vorgängern so inkompatibel werden, daß es letztlich nicht mehr Zot heißen sollte. Aber es gab Leute, die Osada, Misty oder Redmatrix produktiv nutzten.
Also mußte Mike von einem von den dreien Roadhouse forken. War ihm aber egal, weil er damit die Leute mit noch einer weiteren Marke trollen konnte. Wohlgemerkt, effektiv hatte er sogar Zap noch an der Backe, weil es in der Community dann wohl doch zuwenig Interesse an der Weiterentwicklung gab.
Nomad, eigentlich ja Zot11, wurde zum Erfolg. Und das Erfolgsrezept lag auch darin, zusätzlich Support für Hubzillas Zot6 einzubauen, über den Roadhouse auch mit Osada, Misty und Redmatrix kommunizieren konnte. Ansonsten waren von den praktischen Features her Zap, Osada, Misty, Redmatrix und Roadhouse identisch und von der Benutzeroberfläche her auch beinahe. Es machte in der Praxis keinen großen Unterschied, welches man nutzte. Außerhalb waren sie eh, wenn überhaupt, nur auf Hubzilla bekannt. Das heißt, Roadhouse war beinahe komplett unbekannt, weil da endgültig nur Mike drüber redete.
Daß es (streams) gibt, obwohl Roadhouse doch gut war, hatte andere Gründe.
Grund 1: Mike fand einen neuen Weg, die Markenfetischisten zu trollen. Nämlich mit Software, die gar keinen Namen und gar keine Markenidentität hat. Also nahm Mike dem neuen Roadhouse-Fork von Ende 2021 den Namen und sogar den fediverseinternen festen Identifikator weg. Letzteren kann man entweder händisch ausfüllen, oder (streams) übernimmt ihn vom Instanznamen. Alleine das wäre mit einem "Debranding" von Roadhouse nicht getan gewesen, weil weiter alle von "Roadhouse" gesprochen hätten.
Grund 2: Dieses ständige Wetteifern, welche Software auf The Federation, Fediverse Observer, der FediDB usw. jetzt am populärsten ist und am meisten genutzt wird, ging ihm inzwischen auch auf dem Zeiger. Ein weiteres "Feature" von (streams) ist, daß Mike neben dem Namen und der Markenidentität auch nodeinfo praktisch komplett entfernt hat. (streams) sendet überhaupt keine Statistiken und hält sich von allen Instanzlisten-Websites fern. Und das ist so gewollt.
Grund 3: Zusätzlich wollte Mike es der Free-Software- und Open-Source-Community leichter machen. Da kloppt man sich ja bekanntlich darum, welche Lizenzen wirklich frei sind und welche nicht. Also hat Mike (streams), dessen sämtliche Vorgänger unter der MIT-Lizenz stehen, in die Public Domain gestellt. Freier als das geht's nun wirklich nicht mehr. Gleichzeitig wollte Mike diejenigen ärgern, die vielleicht vorhaben könnten, aus (streams) proprietäre, kommerzielle Closed-Source-Software zu machen. Die ganzen Apps sind nämlich durchaus schon mal Fremdcode und stehen unter eigenen Lizenzen. Und die sind untereinander inkompatibel.
(streams) sollte stabil werden und wurde stabil. Im Grunde war Mikes Plan, (streams) zu der Fediverse-Software der Zukunft zu machen. So hat er am 31.12.2022 offiziell Zap, Osada, Misty, Redmatrix und Roadhouse eingestellt. Das war aber kein Problem, denn zwischen den fünfen konnten Admins durch einfaches Rebasen nicht nur crossgraden, sondern auch zu (streams) upgraden.
Jetzt gab es nur noch Friendica, Hubzilla und (streams), wovon Mike nur noch (streams) betreute.
Dann kam ja silverpill auf Mike zu mit der Idee der nomadischen Identität über ActivityPub. Mike war interessiert. silverpill trieb das ziemlich voran inklusive dem einen oder anderen neuen FEP, darunter auch FEP-ef61, das in ActivityPub dezentrale Identitäten einführen sollte. Zot hat so etwas, Nomad natürlich auch, aber anders, und ActivityPub hatte das natürlich nicht.
Diese dezentralen Identitäten hat Mike auch in (streams) eingebaut. Langfristig sollte es ja möglich sein, zwischen verschiedenen Serveranwendungen zu klonen, so auch zwischen (streams) und Mitra. Zumindest aber sollten sie voneinander die dezentralen Identitäten als ebensolche verstehen. So sollte (streams) geklonte Mitra-Identitäten als solche erkennen, und Mitra sollte geklonte (streams)-Kanäle als solche erkennen.
Unter Laborbedingungen in Mikes nomadic-Zweig funktionierten die. Also mergete Mike im Juni 2024 den nomadic-Zweig in den dev-Zweig, den allgemeinen Entwicklungszweig. Auch der lief nur unter Laborbedingungen, weil (im Gegensatz zu Hubzilla, wo zwei öffentliche Produktivhubs Entwicklerversionen fahren) niemand außer Mike den dev-Zweig von (streams) produktiv fuhr.
Im Juli 2024 mergete Mike dann den dev-Zweig in den release-Zweig, um die neuesten Weiterentwicklungen an die produktiv gefahrenen, stabilen Server auszurollen. Da war allerdings Schluß mit Laborbedingungen. Jetzt mußten sich FEP-ef61 und die DIDs unter täglichen und breitgefächerten Realbedingungen beweisen.
Genau das taten sie nicht. Erst jetzt stellte sich heraus, daß (streams) mit den vielen Identitäten nicht klarkam. Es föderierte nicht mehr über ActivityPub. Es föderierte nicht mehr mit Hubzilla. Es föderierte nicht mal mehr mit sich selbst. Es konnte sich mit nichts mehr vernünftig verbinden.
Mike brauchte eine Weile, um überhaupt festzustellen, daß der Verursacher dieser Misere ein Identitätenchaos war. Das konnte er aber nicht auf (streams) selbst beheben. Hilfe hatte er auch keine. Die (streams)-Community war so winzig, da gab es niemanden, der ihm hätte helfen können. Der einzige, der die Fähigkeit gehabt hätte, hatte keine Zeit. Und der einzige, der Zeit und Bock hatte, hatte vom Coden keine Ahnung.
So mußte Mike sich erstmal einen Überblick verschaffen. Im August, also dem Monat nach dem Crash, als der Crash noch nicht behoben war, forkte er das streams-Repository und schuf Forte. Da wiederum riß er alles raus, was nicht ActivityPub war, also die Unterstützung sowohl von Nomad als auch von Zot6, um einen freien, ungehinderten Blick auf ActivityPub zu haben.
Inzwischen hatte er auch zwei andere Sachen gelernt: Software, die keinen Namen hat, interessiert keinen. Das verwirrt die Leute eher. Also bekam Forte wieder einen Namen. Die Public Domain brachte auch nichts. Also kam Forte wieder unter die MIT-Lizenz. Und Fediverse-Software, die überhaupt keine nodeinfo hat, ist praktisch unsichtbar. Also bekam Forte wieder nodeinfo, zunächst aber, ohne brauchbare Zahlen zu versenden. So konnte Forte zumindest vom Fediverse Observer und später vom FediIndex gelistet werden.
Forte half ihm, die ID-Misere zu entwirren, zu entflechten und zu lösen. Das reichte er dann auch nach (streams) weiter, das allmählich wieder funktionierte. Allerdings brannte er sich in dem August derart aus, daß er zum 31.8.2024 offiziell sowohl das streams-Repository als auch Forte zur Übernahme anbot und seinen Ruhestand ankündigte.
Dieses Mal fand eine Übernahme gleich gar nicht statt. Wie gesagt, in der (streams)-Community gab es niemanden, der sowohl die Zeit als auch das Know-how hatte, um auch nur Mike zu helfen, geschweige denn, eine Rolle wie Tobias oder Michael oder Mario anzunehmen.
Außerhalb von (streams) war (streams) selbst sogar auf Hubzilla kaum bekannt. Forte war sogar auf Hubzilla noch unbekannter, zumal es noch eine obskure, nichtöffentliche Bastelbude war, bis Mike im September 2024 die erste "offizielle" Entwicklerversion von Forte (und damit Forte selbst) veröffentlichte.
Und außerhalb von Hubzilla? Mike war es so leid, daß Mastodon als alternativlose Referenzimplementation des Fediverse angesehen wurde, daß er um 2023 anfing, Werbung für (streams) zu machen. Das erste Mal überhaupt, daß Mike von "wenn du es baust, werden sie kommen" abkam (es kam ja keiner) und irgendwas bewarb. Nur wußte Mike nicht, wie man zu Mastodon-Leuten spricht; ehrlich gesagt, das weiß auch auf Friendica und Hubzilla kaum jemand.
Oft genug ging aus Mikes Posts nicht mal hervor, daß er über ein konkretes Fediverse-Produkt sprach, und schon gar nicht, über welches. Wie auch, sprach er doch von etwas Namenlosem. Das heißt, auch er fing langsam an, den Namen des Repository zu verwenden. Aber er machte nicht unbedingt wirklich glasklar, daß er von etwas sprach, das jetzt in diesem Augenblick im Fediverse existierte. Schon gar nicht erwähnte er, daß es auch mit Mastodon verbunden ist, denn kaum jemand außerhalb von Mastodon weiß, daß Mastodon-Nutzer das nicht unbedingt automatisch verstehen.
Stand Mitte September 2024 hatte (streams) keine 100 aktiven Nutzer und Forte außer Mike gar keine. Traurigerweise hatte (streams) damals mehr öffentliche Server als heute, derweil Forte anderthalb Jahre gebraucht hat, um auch nur einen hervorzubringen. Wo sollen da Entwickler herkommen?
Mike hat übrigens nicht vor, (streams) einzustellen. Er und nicht nur er sagt, (streams) hat weiterhin seine Existenzberechtigung, und zwar als moderne Fediverse-Software, die von ActivityPub unabhängig ist. Er und nicht nur er sieht den ActivityPub-Schalter als eine Art letztes Bollwerk gegen Mastodon an und das einzige, das auf Kanalebene funktioniert, also nicht nur serverweit.
So, nun noch das Wort zu Smartphone-Apps.
Von Mike selbst war da nie etwas zu erwarten. Fediverse-Apps sind reine Frontend-Sachen. Und wir sollten inzwischen wissen, daß Mike nicht mal Web-UIs kann. Hubzilla ist für seine Oberfläche berüchtigt. Es ist doch erst schick geworden, als Saiwal mit seinen Utsukta-Themes anfing.
Außerdem hatte Mike immer schon genügend mit Webentwicklung zu tun. Da konnte man von ihm nicht auch noch erwarten, eine Smartphone-App zu entwickeln. Besser gesagt, zwei Smartphone-Apps, weil die iOS-App wahrscheinlich separat hätte entwickelt werden müssen. Mike wäre ja auch keiner gewesen, der in einer Smartphone-App nur das nötigste an Features eingebaut hätte. Wenn, dann alles. Er hätte also neben der Serversoftware zwei ziemliche Monster-Apps entwickeln und pflegen müssen.
Apps von Drittentwicklern?
Guck dir mal an, wie lange es gedauert hat, bis es von RaccoonForFriendica einen öffentlich verfügbaren Android-Release gab. Für iOS ist es meines Wissens bis heute nur über TestDrive verfügbar, aber nicht im App Store. Und selbst auf Android ist es noch nicht so stabil und fully featured, daß man es als Daily Driver nutzen könnte.
Für Hubzilla gab es mal Nomad für Android. Das wird seit gut sechs Jahren nicht mehr weiterentwickelt. Unter aktuellen Android-Versionen läuft es inzwischen gar nicht mehr. Und auch das ist nur ein Wrapper für die Weboberfläche, also ein glorifizierter Webbrowser. Ansonsten gibt's nur eine Minimalst-App von Mario, mit der er mal versuchsweise getestet hat, ob man von Android aus nach Hubzilla posten kann. Das ist absolut das einzige, was die App überhaupt kann.
Hubzilla hat eine Client API. Ob die aber funktioniert, ist weitestgehend unbekannt, weil noch nie jemand versucht hat, dagegen eine hinreichend mit Features ausgestattete App zu bauen. Dasselbe dürfte für (streams) und Forte gelten, für die es überhaupt noch nie irgendwelche Apps gegeben hat. Alle drei setzen statt dessen auf den Einsatz als PWA, nur daß da draußen keine Sau weiß, daß es das überhaupt gibt, geschweige denn, wie man das einrichtet.
Auf Drittentwickler kann man hier erst recht nicht hoffen. Von den Leuten im Fediverse, die Smartphone-Apps entwickeln können, kennt genau niemand Hubzilla, geschweige denn (streams) oder Forte. Selbst wenn sie Hubzilla kennenlernen würden, hätten sie keinen Bock, dafür eine App zu entwickeln. Lohnt sich nicht, weil nutzt keiner. Es lohnt sich viel mehr, die drölfzigtausendste reine Mastodon-App fürs iPhone zu bauen. Das heißt, mindestens die Hälfte von denen weiß doch sowieso nicht, was es außer Mastodon sonst noch so im Fediverse gibt.
Auf Hubzilla selbst gibt's nicht einen Mobilentwickler. Auf (streams) und Forte dürfte es niemanden geben, der überhaupt wirklich irgendwas entwickeln kann, nicht mal Webanwendungen (sonst hätte Mike Hilfe), Smartphone-Apps schon gar nicht.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendica #RedMatrix #Hubzilla #Osada #Zap #Roadhouse #Streams #(streams) #Forte -
@Kristian Na ja, Friendica war ja ausgereift. Zumindest soweit ausgereift, wie Friendica selbst und das DFRN-Protokoll es zuließen. Smartphone-Apps gab es nicht, weil man damals, 2010/2011, Smartphone-Apps für Sachen, die es auch als Websites gab, noch als Gimmicks ansah und noch nicht als lebensnotwendig. Das war, bevor die Leute gewisse Websites mehr über dedizierte Apps nutzten als über die Websites selbst.
Nur: Eine Weiterentwicklung war zwingend notwendig. Und die ging nicht mit Friendica, wie es war, denn die ging auch nicht mit DFRN.
Der Auslöser: 2011 waren binnen kurzer Zeit mehrere größere Friendica-Nodes von jetzt auf sofort ohne Ankündigung verschwunden. Einfach so weg. Friendica war durch das Verschwinden einiger weniger, aber jeweils sehr großer öffentlicher Nodes auf die Hälfte seiner Größe geschrumpft. Die andere Hälfte der Nutzer hatte alles verloren ohne die Chance, irgendwas zu retten. Die konnten wieder ganz neu bei null anfangen.
Das beste, was Mike an Friendica selbst machen konnte, war, eine Export- und Importfunktion einzubauen. Damit konnte man Backups des eigenen Konto machen. Das half aber nur, wenn man entweder brav ein tägliches Backup machte oder die Schließung eines Node vorher angekündigt wurde. Noch einmal: Genau das war 2011 nicht passiert. Die Nodes waren einfach futsch. Da hilft dir auch eine Backup-Funktion nicht, wenn du nicht laufend regelmäßig Backups machst.
Mike sah nur eine mögliche wirkliche Lösung. Und das war, indem deine Identität nicht bombenfest an einen Server gebunden ist, sondern simultan gleichzeitig als identische Klone auf mehreren unabhängigen Servern existieren kann. Wenn davon mal einer ausfällt, egal, die anderen laufen ja noch, also läuft deine Identität noch.
Problem: Mit DFRN ging das nicht umzusetzen. Es brauchte ein ganz neues Protokoll. Auch deshalb, weil Mike noch andere Verbesserungen im Kopf hatte wie ein nochmals deutlich aufgebohrtes Berechtigungssystem. Auch das ging mit DFRN so nicht und brauchte ein neues Protokoll. So entstand Zot.
Zum einen hieß ein neues Protokoll aber auch, wo auch immer das eingebaut werden soll, muß das komplette Backend ausgetauscht und neu geschrieben werden. Und große Teile des Frontend gleich mit. Das konnte Mike aber nicht auf Friendica im laufenden Betrieb machen. Friendica hätte unmöglich seine Grundfunktionalität gleichzeitig auf DFRN und auf Zot betreiben können. Und ein Protokollaustausch hätte bedeutet, daß Nodes, die die neue Friendica-Version mit Zot fahren, sich nicht mehr nativ hätten verbinden können mit Nodes, die alte Versionen mit DFRN fahren. Die wären zueinander inkompatibel gewesen.
Mike hatte als neue Entwicklungsplattform ja gerade das neue Red, das ein Fork seiner bisherigen "geheimen" Entwicklungsplattform Free-Friendika war. Das war ebenso "geheim", das konnte er also entsprechend umbauen.
Mike hätte aber niemals gleichzeitig Red komplett umbauen und Friendica selbst auf Free-Friendika weiterpflegen und die Weiterentwicklungen von Free-Friendika nach Friendica selbst bringen können. Und die einzige Alternative zum Umbau von Red auf Zot war, wieder solche Massencrashs wie 2011 mit exakt denselben Auswirkungen zu haben, ohne irgendwas tun zu können.
Also hat Mike sich auf Red konzentriert (dessen Umbau ja alleine schon länger dauern sollte als die Entwicklung von Friendica) und Friendica in die Hände von Tobias und Michael gegeben, die es seitdem nach ihren Vorstellungen weiterentwickeln. Die beiden waren ja meines Wissens sowieso schon Co-Entwickler von Friendica. Das hat Mike ja längst nicht mehr alles alleine gemacht.
Bei Red war das wieder anders. Das machte Mike ganz alleine. Das mußte er ja erstmal aufbauen. Und selbst als es fertig war, wurde es kaum angenommen. Es war zwar kein Geheimprojekt mehr, nachdem es sich von Friendica gelöst hatte. Aber es wurde kaum angenommen.
Auch als es umbenannt wurde in Red Matrix, was es leichter machte, es zu googlen, wurde es nicht angenommen. Die Friendica-Nutzer nahmen es wahr als Friendica mit nomadischer Identität. Was nomadische Identität ist, verstanden sie gar nicht. Selbst wenn doch: Die meisten von ihnen hatten inzwischen ihre eigenen privaten Einzelnutzer-Nodes.
So sahen sie in der Red Matrix gegenüber Friendica keine Vorteile, also warum umsteigen? Mal ganz davon abgesehen, daß Friendica und die Red Matrix nur über das diaspora*-Protokoll oder OStatus kommunizieren konnten. Die einzigen, die wechselten, dürften die gewesen sein, die eh immer das neueste, heißeste Zeug ausprobieren wollten.
Außerhalb von Friendica wußte eh keine Sau, daß die Red Matrix existierte. Herzlich wenige Leute wußten ja überhaupt auch nur, daß Friendica existierte. Mikes "Wenn du es baust, werden sie kommen" funktionierte damals schon nicht. Kleckerweise kamen noch neue Leute nach Friendica. Aber kaum einer ging von Friendica auf die Red Matrix, und absolut niemand ging von null auf die Red Matrix.
Interessant wurde die Red Matrix eigentlich erst 2015, als sie zu Hubzilla aufgebohrt wurde, also auf einmal Sachen konnte, die Friendica nicht konnte, die aber vielleicht nützlich sein konnten. Damit konnte Hubzilla auch für ganz andere Sachen eingesetzt werden als Friendica, also nicht nur als Facebook-Ersatz oder Blog.
Aber wenn Mario schon Anfang 2015 das noch brandneue Hubzilla übernahm, was ja so auf der offiziellen Website steht (nach meinen Informationen war es erst 2018), dann war es ein Wunder, daß Mike überhaupt jemanden fand, der übernehmen würde, der also schon seit Red-Matrix-Zeiten dabei war. Aber Mike hat ja an der Weiterentwicklung von Hubzilla noch weiter aktiv mitgewirkt, nur eben nicht als Projektleiter.
Hubzilla selbst wurde ja erst ab Ende 2015 interessant, als es seinen ersten stabilen Release hatte. Und auch Hubzillas Existenz war eigentlich nur auf Friendica bekannt. Selbst heute noch sind die allermeisten Hubzilla-Nutzer Friendica-Veteranen. Direkt von Mastodon nach Hubzilla ist kaum einer gekommen, von null nach Hubzilla schon gar nicht.
Selbst da war Mike keiner, der Sachen so läßt, wie sie sind, und sie nur noch weiter poliert. Wenn es etwas zu verbessern gibt, dann macht er das auch. Und wenn das nicht auf existierender Software im laufenden Produktivbetrieb geht, dann forkt er eben, und dann nimmt er sich weit mehr Zeit für seinen Fork als für das, was er vorher gemacht hatte. Und das ist auch gut so. Ansonsten hätten wir heute noch nur Friendica und immer noch keine Lösung für das Problem, daß die Leute alles verlieren, wenn mal wieder ein großer Node verschwindet.
Jetzt wollte Mike Zot weiterentwickeln, wohl auch deshalb, weil Zot, wie es damals war, nicht gut mit ActivityPub zusammenspielte. Aber potentiell kompatibilitätsbrechend. In einem eigenen zusätzlichen Branch von Hubzilla wäre das nicht gegangen, schon deshalb, weil Hubzilla für solche Experimente schlicht und ergreifend zu groß war.
Also hat Mike 2018 Osada von Hubzilla abgeforkt und alles rausgerissen, was im Weg war. Artikel, Karten, Wikis, Webpages, alle Verbindungsmöglichkeiten außer Zot, ActivityPub und RSS/Atom, alles raus.
Weil dann abzusehen war, daß nomadisches Zot6 (zumindest vorerst) mit ActivityPub überhaupt nicht mehr funktionieren würde, brauchte Mike zwei Projekte: Osada behielt ActivityPub, wurde aber nichtnomadisch. Zusätzlich forkte er Zap von Osada, ließ es nomadisch, entfernte aber ActivityPub.
Jetzt konnte Mike endgültig nicht gleichzeitig Zot6 entwickeln und Osada entwickeln und Zap entwickeln und Hubzilla weiterpflegen. Auch dieses Mal half ihm bei den Neuentwicklungen niemand. Also überließ er Hubzilla gänzlich Mario.
Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.
Anfang 2019 fand er einen Weg, auch nomadisches Zot6 mit ActivityPub kompatibel zu machen. Abgesehen davon war die Idee, einen nomadischen Zap-Kanal über einen nichtnomadischen Osada-Kanal mit dem Fediverse zu verbinden, sowieso kompletter Blödsinn und technisch in der Praxis kaum realisierbar, selbst mit Kanalquellen nicht. Also stellte Mike Osada ein, forkte von Zap ein ganz neues Osada und baute da ActivityPub-Support ein. Noch war nomadisches Zot6 + ActivityPub ja noch experimentell, deswegen hat er es nicht in Zap eingebaut.
Dann aber wurden Osada und Zap stabil und bekamen sogar einen 1.0-Release. Inzwischen gab es Leute, die Osada oder Zap produktiv nutzten. Die kamen alle von Hubzilla, denn nur da wußte man, daß es Osada und Zap gab. Nicht mal auf Friendica wußte das jemand, im übrigen Fediverse erst recht nicht und außerhalb des Fediverse schon gar nicht.
So baute Mike dann Osadas ActivityPub-Support auch in Zap ein, schaltete ihn aber standardmäßig auf Serverebene ab, auf Kanalebene sowieso. Das führte dazu, daß Osada und Zap bis auf das Branding und die Standardeinstellungen völlig identisch waren. Es brauchte gar nicht mehr beide. Mike ließ das aber so.
Irgendwie gab es wohl genug Osada- und Zap-Anwender, daß Mike jemanden fand, der beides weiterpflegen wollte. Denn Mike hatte wieder neue Weiterentwicklungen im Sinne, die er aber nicht mehr auf Osada und Zap machen konnte, weil die jetzt beide als stabile Produktivsoftware galten. So gab er Osada und Zap dann wieder an "die Community" weiter, die als quasi erste Amtshandlung mit Mikes Segen Osada nach Zap mergete, in dem Zuge auch auf Zap ActivityPub standardmäßig aktivierte und Osada kurzerhand einstellte.
2020 ging es dann weiter. Zap war damals State of the Art. Zot6 war so stabil, daß es nach Hubzilla zurückportiert wurde. Zap war jetzt quasi der modernere kleine Bruder von Hubzilla, der sich etwas eleganter bediente und einen nicht mit Features erschlug. Nur war Zap immer noch obskurer als Hubzilla, Hubzilla war obskurer als Friendica, und Friendica war selbst sehr obskur, weil für keins der drei wirklich Werbung gemacht wurde. Zap war weiterhin sonst nur auf Hubzilla bekannt und Hubzilla sonst nur auf Friendica.
Und Mike bastelte an Zot8, das nochmals besser werden sollte. Dafür brauchte er aber Software zum Experimentieren. Und so entstanden drei neue Forks in so kurzer Folge, daß heute nicht mehr bekannt ist, was jetzt wovon geforkt wurde, nur daß irgendwas von Zap geforkt worden ist. Im einzelnen waren das schon wieder ein neues Osada, ein neues Mistpark und eine neue Redmatrix.
Warum drei?
Es ging das Gerücht um, das seien verschiedene Stabilitätsstufen. Redmatrix 2020 sei experimentell mit wie früher bei Zap standardmäßig deaktiviertem ActivityPub, das damit der Entwicklung von Zot8 nicht im Wege stehe. Osada sei auch experimentell, aber wie früher schon bei Osada mit standardmäßig aktiviertem ActivityPub, um zu gucken, wie die Weiterentwicklungen von Zot8 sich mit ActivityPub vertragen. Mistpark 2020 wiederum sei "halbstabil" wie Debian testing, also stabiler als Osada und eher für den Produktiveinsatz geeignet, aber aktueller als Zap.
Zap sei also für die, die etwas neueres als Hubzilla haben wollten und auf die Zusatzfeatures von Hubzilla verzichten konnten. Misty sei für die, die etwas noch aktuelleres als Zap haben wollten, also das neueste Zeug noch früher, und die etwaige Instabilitäten in Kauf zu nehmen bereit waren. Osada sei für die, die unbedingt bleeding-edge wollten, instabil oder nicht. Und Redmatrix 2020 sei eh nur für Mike.
In Wahrheit waren Osada, Misty und Redmatrix 2020 bis auf das Branding völlig identisch und quasi Soft-Forks. Alle Commits wurden gleichermaßen und fast gleichzeitig in alle drei eingepflegt.
Warum?
Weil Mike der Markenfetischismus im Fediverse auf den Keks ging. Es gab Leute, die bildeten sich ein, die Software, die sie nutzten, sei die beste, einfach, weil sie Fans der Softwaremarke waren. Ganz besonders gab es die natürlich auf Mastodon, aber auch sonst. Genau diese Leute wollte er trollen, indem er drei bis auf den Namen und das Logo völlig identische Serveranwendungen pflegte. Misty z. B. konnte überhaupt nicht "die beste Fediverse-Serversoftware" sein, egal, wer sich das einbildete, wenn Osada und Redmatrix bis auf die Marke völlig baugleich waren.
Anfang 2021 kam dann Roadhouse dazu. Das Abenteuer Zot8 war im Grunde vorbei, bevor Zot8 stabil war. Denn Zot11 sollte noch besser werden. Vor allem sollte Zot11 von allen Zot-Versionen die beste Kompatibilität mit ActivityPub bekommen. Blöderweise konnte Mike aber Zot11 nicht auf Osada, Misty und Redmatrix entwickeln. Zot11 sollte nämlich zu allen Vorgängern so inkompatibel werden, daß es letztlich nicht mehr Zot heißen sollte. Aber es gab Leute, die Osada, Misty oder Redmatrix produktiv nutzten.
Also mußte Mike von einem von den dreien Roadhouse forken. War ihm aber egal, weil er damit die Leute mit noch einer weiteren Marke trollen konnte. Wohlgemerkt, effektiv hatte er sogar Zap noch an der Backe, weil es in der Community dann wohl doch zuwenig Interesse an der Weiterentwicklung gab.
Nomad, eigentlich ja Zot11, wurde zum Erfolg. Und das Erfolgsrezept lag auch darin, zusätzlich Support für Hubzillas Zot6 einzubauen, über den Roadhouse auch mit Osada, Misty und Redmatrix kommunizieren konnte. Ansonsten waren von den praktischen Features her Zap, Osada, Misty, Redmatrix und Roadhouse identisch und von der Benutzeroberfläche her auch beinahe. Es machte in der Praxis keinen großen Unterschied, welches man nutzte. Außerhalb waren sie eh, wenn überhaupt, nur auf Hubzilla bekannt. Das heißt, Roadhouse war beinahe komplett unbekannt, weil da endgültig nur Mike drüber redete.
Daß es (streams) gibt, obwohl Roadhouse doch gut war, hatte andere Gründe.
Grund 1: Mike fand einen neuen Weg, die Markenfetischisten zu trollen. Nämlich mit Software, die gar keinen Namen und gar keine Markenidentität hat. Also nahm Mike dem neuen Roadhouse-Fork von Ende 2021 den Namen und sogar den fediverseinternen festen Identifikator weg. Letzteren kann man entweder händisch ausfüllen, oder (streams) übernimmt ihn vom Instanznamen. Alleine das wäre mit einem "Debranding" von Roadhouse nicht getan gewesen, weil weiter alle von "Roadhouse" gesprochen hätten.
Grund 2: Dieses ständige Wetteifern, welche Software auf The Federation, Fediverse Observer, der FediDB usw. jetzt am populärsten ist und am meisten genutzt wird, ging ihm inzwischen auch auf dem Zeiger. Ein weiteres "Feature" von (streams) ist, daß Mike neben dem Namen und der Markenidentität auch nodeinfo praktisch komplett entfernt hat. (streams) sendet überhaupt keine Statistiken und hält sich von allen Instanzlisten-Websites fern. Und das ist so gewollt.
Grund 3: Zusätzlich wollte Mike es der Free-Software- und Open-Source-Community leichter machen. Da kloppt man sich ja bekanntlich darum, welche Lizenzen wirklich frei sind und welche nicht. Also hat Mike (streams), dessen sämtliche Vorgänger unter der MIT-Lizenz stehen, in die Public Domain gestellt. Freier als das geht's nun wirklich nicht mehr. Gleichzeitig wollte Mike diejenigen ärgern, die vielleicht vorhaben könnten, aus (streams) proprietäre, kommerzielle Closed-Source-Software zu machen. Die ganzen Apps sind nämlich durchaus schon mal Fremdcode und stehen unter eigenen Lizenzen. Und die sind untereinander inkompatibel.
(streams) sollte stabil werden und wurde stabil. Im Grunde war Mikes Plan, (streams) zu der Fediverse-Software der Zukunft zu machen. So hat er am 31.12.2022 offiziell Zap, Osada, Misty, Redmatrix und Roadhouse eingestellt. Das war aber kein Problem, denn zwischen den fünfen konnten Admins durch einfaches Rebasen nicht nur crossgraden, sondern auch zu (streams) upgraden.
Jetzt gab es nur noch Friendica, Hubzilla und (streams), wovon Mike nur noch (streams) betreute.
Dann kam ja silverpill auf Mike zu mit der Idee der nomadischen Identität über ActivityPub. Mike war interessiert. silverpill trieb das ziemlich voran inklusive dem einen oder anderen neuen FEP, darunter auch FEP-ef61, das in ActivityPub dezentrale Identitäten einführen sollte. Zot hat so etwas, Nomad natürlich auch, aber anders, und ActivityPub hatte das natürlich nicht.
Diese dezentralen Identitäten hat Mike auch in (streams) eingebaut. Langfristig sollte es ja möglich sein, zwischen verschiedenen Serveranwendungen zu klonen, so auch zwischen (streams) und Mitra. Zumindest aber sollten sie voneinander die dezentralen Identitäten als ebensolche verstehen. So sollte (streams) geklonte Mitra-Identitäten als solche erkennen, und Mitra sollte geklonte (streams)-Kanäle als solche erkennen.
Unter Laborbedingungen in Mikes nomadic-Zweig funktionierten die. Also mergete Mike im Juni 2024 den nomadic-Zweig in den dev-Zweig, den allgemeinen Entwicklungszweig. Auch der lief nur unter Laborbedingungen, weil (im Gegensatz zu Hubzilla, wo zwei öffentliche Produktivhubs Entwicklerversionen fahren) niemand außer Mike den dev-Zweig von (streams) produktiv fuhr.
Im Juli 2024 mergete Mike dann den dev-Zweig in den release-Zweig, um die neuesten Weiterentwicklungen an die produktiv gefahrenen, stabilen Server auszurollen. Da war allerdings Schluß mit Laborbedingungen. Jetzt mußten sich FEP-ef61 und die DIDs unter täglichen und breitgefächerten Realbedingungen beweisen.
Genau das taten sie nicht. Erst jetzt stellte sich heraus, daß (streams) mit den vielen Identitäten nicht klarkam. Es föderierte nicht mehr über ActivityPub. Es föderierte nicht mehr mit Hubzilla. Es föderierte nicht mal mehr mit sich selbst. Es konnte sich mit nichts mehr vernünftig verbinden.
Mike brauchte eine Weile, um überhaupt festzustellen, daß der Verursacher dieser Misere ein Identitätenchaos war. Das konnte er aber nicht auf (streams) selbst beheben. Hilfe hatte er auch keine. Die (streams)-Community war so winzig, da gab es niemanden, der ihm hätte helfen können. Der einzige, der die Fähigkeit gehabt hätte, hatte keine Zeit. Und der einzige, der Zeit und Bock hatte, hatte vom Coden keine Ahnung.
So mußte Mike sich erstmal einen Überblick verschaffen. Im August, also dem Monat nach dem Crash, als der Crash noch nicht behoben war, forkte er das streams-Repository und schuf Forte. Da wiederum riß er alles raus, was nicht ActivityPub war, also die Unterstützung sowohl von Nomad als auch von Zot6, um einen freien, ungehinderten Blick auf ActivityPub zu haben.
Inzwischen hatte er auch zwei andere Sachen gelernt: Software, die keinen Namen hat, interessiert keinen. Das verwirrt die Leute eher. Also bekam Forte wieder einen Namen. Die Public Domain brachte auch nichts. Also kam Forte wieder unter die MIT-Lizenz. Und Fediverse-Software, die überhaupt keine nodeinfo hat, ist praktisch unsichtbar. Also bekam Forte wieder nodeinfo, zunächst aber, ohne brauchbare Zahlen zu versenden. So konnte Forte zumindest vom Fediverse Observer und später vom FediIndex gelistet werden.
Forte half ihm, die ID-Misere zu entwirren, zu entflechten und zu lösen. Das reichte er dann auch nach (streams) weiter, das allmählich wieder funktionierte. Allerdings brannte er sich in dem August derart aus, daß er zum 31.8.2024 offiziell sowohl das streams-Repository als auch Forte zur Übernahme anbot und seinen Ruhestand ankündigte.
Dieses Mal fand eine Übernahme gleich gar nicht statt. Wie gesagt, in der (streams)-Community gab es niemanden, der sowohl die Zeit als auch das Know-how hatte, um auch nur Mike zu helfen, geschweige denn, eine Rolle wie Tobias oder Michael oder Mario anzunehmen.
Außerhalb von (streams) war (streams) selbst sogar auf Hubzilla kaum bekannt. Forte war sogar auf Hubzilla noch unbekannter, zumal es noch eine obskure, nichtöffentliche Bastelbude war, bis Mike im September 2024 die erste "offizielle" Entwicklerversion von Forte (und damit Forte selbst) veröffentlichte.
Und außerhalb von Hubzilla? Mike war es so leid, daß Mastodon als alternativlose Referenzimplementation des Fediverse angesehen wurde, daß er um 2023 anfing, Werbung für (streams) zu machen. Das erste Mal überhaupt, daß Mike von "wenn du es baust, werden sie kommen" abkam (es kam ja keiner) und irgendwas bewarb. Nur wußte Mike nicht, wie man zu Mastodon-Leuten spricht; ehrlich gesagt, das weiß auch auf Friendica und Hubzilla kaum jemand.
Oft genug ging aus Mikes Posts nicht mal hervor, daß er über ein konkretes Fediverse-Produkt sprach, und schon gar nicht, über welches. Wie auch, sprach er doch von etwas Namenlosem. Das heißt, auch er fing langsam an, den Namen des Repository zu verwenden. Aber er machte nicht unbedingt wirklich glasklar, daß er von etwas sprach, das jetzt in diesem Augenblick im Fediverse existierte. Schon gar nicht erwähnte er, daß es auch mit Mastodon verbunden ist, denn kaum jemand außerhalb von Mastodon weiß, daß Mastodon-Nutzer das nicht unbedingt automatisch verstehen.
Stand Mitte September 2024 hatte (streams) keine 100 aktiven Nutzer und Forte außer Mike gar keine. Traurigerweise hatte (streams) damals mehr öffentliche Server als heute, derweil Forte anderthalb Jahre gebraucht hat, um auch nur einen hervorzubringen. Wo sollen da Entwickler herkommen?
Mike hat übrigens nicht vor, (streams) einzustellen. Er und nicht nur er sagt, (streams) hat weiterhin seine Existenzberechtigung, und zwar als moderne Fediverse-Software, die von ActivityPub unabhängig ist. Er und nicht nur er sieht den ActivityPub-Schalter als eine Art letztes Bollwerk gegen Mastodon an und das einzige, das auf Kanalebene funktioniert, also nicht nur serverweit.
So, nun noch das Wort zu Smartphone-Apps.
Von Mike selbst war da nie etwas zu erwarten. Fediverse-Apps sind reine Frontend-Sachen. Und wir sollten inzwischen wissen, daß Mike nicht mal Web-UIs kann. Hubzilla ist für seine Oberfläche berüchtigt. Es ist doch erst schick geworden, als Saiwal mit seinen Utsukta-Themes anfing.
Außerdem hatte Mike immer schon genügend mit Webentwicklung zu tun. Da konnte man von ihm nicht auch noch erwarten, eine Smartphone-App zu entwickeln. Besser gesagt, zwei Smartphone-Apps, weil die iOS-App wahrscheinlich separat hätte entwickelt werden müssen. Mike wäre ja auch keiner gewesen, der in einer Smartphone-App nur das nötigste an Features eingebaut hätte. Wenn, dann alles. Er hätte also neben der Serversoftware zwei ziemliche Monster-Apps entwickeln und pflegen müssen.
Apps von Drittentwicklern?
Guck dir mal an, wie lange es gedauert hat, bis es von RaccoonForFriendica einen öffentlich verfügbaren Android-Release gab. Für iOS ist es meines Wissens bis heute nur über TestDrive verfügbar, aber nicht im App Store. Und selbst auf Android ist es noch nicht so stabil und fully featured, daß man es als Daily Driver nutzen könnte.
Für Hubzilla gab es mal Nomad für Android. Das wird seit gut sechs Jahren nicht mehr weiterentwickelt. Unter aktuellen Android-Versionen läuft es inzwischen gar nicht mehr. Und auch das ist nur ein Wrapper für die Weboberfläche, also ein glorifizierter Webbrowser. Ansonsten gibt's nur eine Minimalst-App von Mario, mit der er mal versuchsweise getestet hat, ob man von Android aus nach Hubzilla posten kann. Das ist absolut das einzige, was die App überhaupt kann.
Hubzilla hat eine Client API. Ob die aber funktioniert, ist weitestgehend unbekannt, weil noch nie jemand versucht hat, dagegen eine hinreichend mit Features ausgestattete App zu bauen. Dasselbe dürfte für (streams) und Forte gelten, für die es überhaupt noch nie irgendwelche Apps gegeben hat. Alle drei setzen statt dessen auf den Einsatz als PWA, nur daß da draußen keine Sau weiß, daß es das überhaupt gibt, geschweige denn, wie man das einrichtet.
Auf Drittentwickler kann man hier erst recht nicht hoffen. Von den Leuten im Fediverse, die Smartphone-Apps entwickeln können, kennt genau niemand Hubzilla, geschweige denn (streams) oder Forte. Selbst wenn sie Hubzilla kennenlernen würden, hätten sie keinen Bock, dafür eine App zu entwickeln. Lohnt sich nicht, weil nutzt keiner. Es lohnt sich viel mehr, die drölfzigtausendste reine Mastodon-App fürs iPhone zu bauen. Das heißt, mindestens die Hälfte von denen weiß doch sowieso nicht, was es außer Mastodon sonst noch so im Fediverse gibt.
Auf Hubzilla selbst gibt's nicht einen Mobilentwickler. Auf (streams) und Forte dürfte es niemanden geben, der überhaupt wirklich irgendwas entwickeln kann, nicht mal Webanwendungen (sonst hätte Mike Hilfe), Smartphone-Apps schon gar nicht.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendica #RedMatrix #Hubzilla #Osada #Zap #Roadhouse #Streams #(streams) #Forte -
One of my fears of homelabbing is the reliance on (3rd party) #Docker/#container images that could just be gone someday. I've already had it happen once, with #Bitnami images (fuck #Broadcom).
One way I previously thought to combat this is to manually pull the image bundle and host it in your own container registry. This works, but obviously not a reasonable effort to do and reproduce for more than ~1-2 images.
Then, the moment I discovered #Amazon/#AWS has such a thing that addresses this - pull through cache for their #ECR, I looked up on how I can have the same kind of setup on my #homelab, and sure enough, there are already several options. I went with #Zot, and it's working pretty freaking well. Now, anytime I pull any images from registries I've configured Zot to sync like #GitHub'sghcr.io,docker.io,public.ecr.aws, they'll all be pulled/cached first on my own Zot instance and stored for good there.
Man, I wish I looked into this much earlier - but better late than never.
🔗 https://github.com/project-zot/zot
🔗 https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html -
One of my fears of homelabbing is the reliance on (3rd party) #Docker/#container images that could just be gone someday. I've already had it happen once, with #Bitnami images (fuck #Broadcom).
One way I previously thought to combat this is to manually pull the image bundle and host it in your own container registry. This works, but obviously not a reasonable effort to do and reproduce for more than ~1-2 images.
Then, the moment I discovered #Amazon/#AWS has such a thing that addresses this - pull through cache for their #ECR, I looked up on how I can have the same kind of setup on my #homelab, and sure enough, there are already several options. I went with #Zot, and it's working pretty freaking well. Now, anytime I pull any images from registries I've configured Zot to sync like #GitHub'sghcr.io,docker.io,public.ecr.aws, they'll all be pulled/cached first on my own Zot instance and stored for good there.
Man, I wish I looked into this much earlier - but better late than never.
🔗 https://github.com/project-zot/zot
🔗 https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html -
One of my fears of homelabbing is the reliance on (3rd party) #Docker/#container images that could just be gone someday. I've already had it happen once, with #Bitnami images (fuck #Broadcom).
One way I previously thought to combat this is to manually pull the image bundle and host it in your own container registry. This works, but obviously not a reasonable effort to do and reproduce for more than ~1-2 images.
Then, the moment I discovered #Amazon/#AWS has such a thing that addresses this - pull through cache for their #ECR, I looked up on how I can have the same kind of setup on my #homelab, and sure enough, there are already several options. I went with #Zot, and it's working pretty freaking well. Now, anytime I pull any images from registries I've configured Zot to sync like #GitHub'sghcr.io,docker.io,public.ecr.aws, they'll all be pulled/cached first on my own Zot instance and stored for good there.
Man, I wish I looked into this much earlier - but better late than never.
🔗 https://github.com/project-zot/zot
🔗 https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html -
One of my fears of homelabbing is the reliance on (3rd party) #Docker/#container images that could just be gone someday. I've already had it happen once, with #Bitnami images (fuck #Broadcom).
One way I previously thought to combat this is to manually pull the image bundle and host it in your own container registry. This works, but obviously not a reasonable effort to do and reproduce for more than ~1-2 images.
Then, the moment I discovered #Amazon/#AWS has such a thing that addresses this - pull through cache for their #ECR, I looked up on how I can have the same kind of setup on my #homelab, and sure enough, there are already several options. I went with #Zot, and it's working pretty freaking well. Now, anytime I pull any images from registries I've configured Zot to sync like #GitHub'sghcr.io,docker.io,public.ecr.aws, they'll all be pulled/cached first on my own Zot instance and stored for good there.
Man, I wish I looked into this much earlier - but better late than never.
🔗 https://github.com/project-zot/zot
🔗 https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html -
One of my fears of homelabbing is the reliance on (3rd party) #Docker/#container images that could just be gone someday. I've already had it happen once, with #Bitnami images (fuck #Broadcom).
One way I previously thought to combat this is to manually pull the image bundle and host it in your own container registry. This works, but obviously not a reasonable effort to do and reproduce for more than ~1-2 images.
Then, the moment I discovered #Amazon/#AWS has such a thing that addresses this - pull through cache for their #ECR, I looked up on how I can have the same kind of setup on my #homelab, and sure enough, there are already several options. I went with #Zot, and it's working pretty freaking well. Now, anytime I pull any images from registries I've configured Zot to sync like #GitHub'sghcr.io,docker.io,public.ecr.aws, they'll all be pulled/cached first on my own Zot instance and stored for good there.
Man, I wish I looked into this much earlier - but better late than never.
🔗 https://github.com/project-zot/zot
🔗 https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html -
@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 -
I've been mostly heads down in the #OCI conformance test redesign. But I managed to ship a new #regclient release yesterday with a feature that will hopefully help the #zot registry.
-
I've been mostly heads down in the #OCI conformance test redesign. But I managed to ship a new #regclient release yesterday with a feature that will hopefully help the #zot registry.
-
I've been mostly heads down in the #OCI conformance test redesign. But I managed to ship a new #regclient release yesterday with a feature that will hopefully help the #zot registry.
-
I've been mostly heads down in the #OCI conformance test redesign. But I managed to ship a new #regclient release yesterday with a feature that will hopefully help the #zot registry.
-
I've been mostly heads down in the #OCI conformance test redesign. But I managed to ship a new #regclient release yesterday with a feature that will hopefully help the #zot registry.
-
#^Hubzilla und das Grid - Wo lässt sich Hubzilla eigentlich einordnen?
Im Zusammenhang mit Hubzilla liest man immer wieder vom "Grid".
Was ist damit denn gemeint? ...
..:: WEITERLESEN ::..
#hubzilla #grid #cms #wordpress #ghost #fediverse #zot #activitypub -
#^Hubzilla und das Grid - Wo lässt sich Hubzilla eigentlich einordnen?
Im Zusammenhang mit Hubzilla liest man immer wieder vom "Grid".
Was ist damit denn gemeint? ...
..:: WEITERLESEN ::..
#hubzilla #grid #cms #wordpress #ghost #fediverse #zot #activitypub -
#^Hubzilla und das Grid - Wo lässt sich Hubzilla eigentlich einordnen?
Im Zusammenhang mit Hubzilla liest man immer wieder vom "Grid".
Was ist damit denn gemeint? ...
..:: WEITERLESEN ::..
#hubzilla #grid #cms #wordpress #ghost #fediverse #zot #activitypub -
#^Hubzilla und das Grid - Wo lässt sich Hubzilla eigentlich einordnen?
Im Zusammenhang mit Hubzilla liest man immer wieder vom "Grid".
Was ist damit denn gemeint? ...
..:: WEITERLESEN ::..
#hubzilla #grid #cms #wordpress #ghost #fediverse #zot #activitypub -
@Gaming on the Fediverse That's quite a bit simplified. For one, four server applications and one protocol were lumped together. Besides, Zap is dead, and Forte isn't even mentioned.
So here's an attempt at telling the whole story (server applications are in bold type, protocols are in bold type and italics):
tl;dr:
2010:- DFRN
- Mistpark/Friendika/Friendica
(DFRN)
- Zot
- Free-Friendika
(DFRN)
(forked from Friendika) - several other Friendika forks
(DFRN)
(forked from Friendika)
(discontinued 2011) - Red/Red Matrix
(DFRN, from 2012 Zot)
(forked from Free-Friendika)
(rebuilt into Hubzilla 2015)
- Hubzilla
(Zot, later Zot6)
(rebuilt from the Red Matrix)
- Zot6
- Osada
(Zot6)
(forked from Hubzilla)
(discontinued in 2018) - Zap
(Zot6)
(forked most likely from Osada, maybe from Hubzilla)
(discontinued in 2022) - Osada
(Zot6)
(forked from Zap)
(discontinued in 2019)
- Zot8
- Redmatrix 2020
(Zot8)
(forked from either Zap or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - Mistpark 2020 a.k.a. Misty
(Zot8)
(forked from either Zap or Redmatrix 2020 or (the third) Osada)
(discontinued in 2022) - Osada
(Zot8)
(forked from either Zap or Redmatrix 2020 or Mistpark 2020)
(discontinued in 2022)
- Nomad
(originally Zot11) - Roadhouse
(Nomad)
(forked from either Redmatrix 2020 or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - (streams)
(Nomad)
(forked from Roadhouse)
Forte
(ActivityPub)
(forked from (streams))[/list]
So as far as Fediverse server applications go, he created Friendica, Free-Friendika, a few more Friendika forks, the Red Matrix, Hubzilla, three Osadas, Zap, Redmatrix 2020, Mistpark 2020, Roadhouse, (streams) and Forte. Depending on how you want to count them, that's at least 13 or 14 server applications. Four of these are still being maintained (Friendica by a new team, Hubzilla by another new team, (streams) and Forte by himself).
The long version:
In 2010, he created- the DFRN protocol
- Mistpark (renamed first into Friendika later in 2010 and then into Friendica in 2011)
In 2011, he made several forks of Friendika. The reason was licensing: Friendika was getting quite some attention. As it was under the MIT license, chances were that it was tempting to fork it and turn the fork into a commercial, proprietary, closed-source monolith or something. On the other hand, the GPL in any shape or form would have hindered further development.
So Mike made a number of forks and relicensed all but one: Free-Friendika kept the MIT license and became the main development platform for Friendika. Friendika itself was relicensed under the AGPLv3.
Shortly afterwards, Mike discontinued all forks except Free-Friendika.
The same year, Mike needed something to keep people from losing everything whenever their Friendika home node was shut down. So he invented nomadic identity and created the Zot protocol.
Also the same year, Mike forked Free-Friendika into Red (spanish la red = the network). It would be renamed Red Matrix in late 2012 because "Red" is hard to Google.
In 2012, Mike rewrote Red almost completely. The whole backend was rebuilt against Zot.
However, the Red Matrix didn't take off. Most Friendica users were hosting their own private nodes. Nomadic identity made no sense for them. Besides, it seemed like many Friendica users didn't understand nomadic identity anyway, so they saw no advantage in the Red Matrix over Friendica, seeing as the features were almost identical otherwise. The Red Matrix had to be made more popular for hosting public servers.
So in 2015, the Red Matrix was rebuilt and greatly expanded into Hubzilla.
In 2018, Mike wanted to develop the Zot protocol further into Zot6. But this would have meant compatibility-breaking changes, also because what he wanted to do with nomadic identity over Zot6 was likely to not work with non-nomadic protocols anymore. So he couldn't do that on Hubzilla.
Instead, he made two new forks:- first Osada, forked from Hubzilla, which was the original Zot6 development platform and then evolved into a non-nomadic "gateway" between Zot6 and everything else
- then Zap, forked most likely from Osada or maybe from Hubzilla, which got the whole Zot6 feature set, including nomadic identity, but which lost support for any and all non-nomadic protocols
A bit later, Zot6 became compatible enough with non-nomadic protocols. Forwarding content from Zap via Osada to the rest of the Fediverse was clunky anyway, forwarding content from the rest of the Fediverse via Osada to Zap even more so. So Osada was discontinued.
Instead, a new Osada was forked from Zap and got ActivityPub support. This and the branding were the only differences between Osada and Zap.
In 2019, when both Osada and Zap had become stable, Zap got ActivityPub support itself. The only difference between the two was now that Osada servers had ActivityPub turned on by default, and Zap servers had it turned off by default. It simply didn't make much sense to keep both alive, so Osada was discontinued again.
I think it was also in 2019 that Hubzilla was upgraded to Zot6.
In 2020, Mike made three more forks to develop Zot8, at least one of which was forked from Zap, and those that weren't were forked from one another: Redmatrix 2020, Mistpark 2020 a.k.a. Misty and Osada.
There was a rumour that Zap was the stable one, Misty was a bit more up-to-date, but potentially less stable, Osada was experimental with ActivityPub support on by default, and Redmatrix 2020 was experimental with ActivityPub support off by default. In fact, however, Misty, Osada and Redmatrix 2020 were absolutely identical in all but branding. Mike kept four server applications around to mess with brand fetishists.
In 2022, Mike forked one of the three into Roadhouse to develop Zot11. But Zot11 was no longer compatible with Zot6 as implemented on Hubzilla and Zap, so he declared it a new protocol named Nomad. Roadhouse got additional support for Zot6.
Now Mike had five server applications, still in order to mess with brand fetishists.
Later the same year, Mike forked Roadhouse into something intentionally nameless and brandless. Again, this was done to troll brand fetishists, this time also to facilitate forking and make people think up their own individual names for the fork rather than keeping the existing one. However, the code repository absolutely required a name, so Mike called it streams.
The community needed something to name this nameless thing by, so they took the name of the repository and wrapped it in parentheses to make sure that this is not actually the name. Ever since, it is colloquially being called (streams). By the way, (streams) is running on what would be Zot12 if it wasn't Nomad now.
On New Year's Eve 2022, Mike discontinued Zap, Redmatrix 2020, Misty, Osada and Roadhouse. (streams) was stable enough, and the other five could be upgraded not only to each other by rebasing the server code, but also to (streams). He asked all admins of Zap, Redmatrix 2020, Misty, Osada and Roadhouse servers to upgrade to (streams).
In 2024, (streams) got bogged down by some identity confusion after the stable release branch introduced decentralised IDs as per FEP-ef61, a part of the development of nomadic identity via ActivityPub. Partially in order to be able to sort this out, partially because the time seemed to have come for this to actually work, Mike forked the streams repository into Forte and removed all support for any protocols other than ActivityPub while still keeping it nomadic. And so Forte became the very first Fediverse server application that establishes nomadic identity via ActivityPub.
CC: @Grow Fediverse
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendika #FreeFriendika #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Redmatrix2020 #Mistpark2020 #Misty #Roadhouse #Streams #(streams) #Forte -
@Gaming on the Fediverse That's quite a bit simplified. For one, four server applications and one protocol were lumped together. Besides, Zap is dead, and Forte isn't even mentioned.
So here's an attempt at telling the whole story (server applications are in bold type, protocols are in bold type and italics):
tl;dr:
2010:- DFRN
- Mistpark/Friendika/Friendica
(DFRN)
- Zot
- Free-Friendika
(DFRN)
(forked from Friendika) - several other Friendika forks
(DFRN)
(forked from Friendika)
(discontinued 2011) - Red/Red Matrix
(DFRN, from 2012 Zot)
(forked from Free-Friendika)
(rebuilt into Hubzilla 2015)
- Hubzilla
(Zot, later Zot6)
(rebuilt from the Red Matrix)
- Zot6
- Osada
(Zot6)
(forked from Hubzilla)
(discontinued in 2018) - Zap
(Zot6)
(forked most likely from Osada, maybe from Hubzilla)
(discontinued in 2022) - Osada
(Zot6)
(forked from Zap)
(discontinued in 2019)
- Zot8
- Redmatrix 2020
(Zot8)
(forked from either Zap or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - Mistpark 2020 a.k.a. Misty
(Zot8)
(forked from either Zap or Redmatrix 2020 or (the third) Osada)
(discontinued in 2022) - Osada
(Zot8)
(forked from either Zap or Redmatrix 2020 or Mistpark 2020)
(discontinued in 2022)
- Nomad
(originally Zot11) - Roadhouse
(Nomad)
(forked from either Redmatrix 2020 or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - (streams)
(Nomad)
(forked from Roadhouse)
Forte
(ActivityPub)
(forked from (streams))[/list]
So as far as Fediverse server applications go, he created Friendica, Free-Friendika, a few more Friendika forks, the Red Matrix, Hubzilla, three Osadas, Zap, Redmatrix 2020, Mistpark 2020, Roadhouse, (streams) and Forte. Depending on how you want to count them, that's at least 13 or 14 server applications. Four of these are still being maintained (Friendica by a new team, Hubzilla by another new team, (streams) and Forte by himself).
The long version:
In 2010, he created- the DFRN protocol
- Mistpark (renamed first into Friendika later in 2010 and then into Friendica in 2011)
In 2011, he made several forks of Friendika. The reason was licensing: Friendika was getting quite some attention. As it was under the MIT license, chances were that it was tempting to fork it and turn the fork into a commercial, proprietary, closed-source monolith or something. On the other hand, the GPL in any shape or form would have hindered further development.
So Mike made a number of forks and relicensed all but one: Free-Friendika kept the MIT license and became the main development platform for Friendika. Friendika itself was relicensed under the AGPLv3.
Shortly afterwards, Mike discontinued all forks except Free-Friendika.
The same year, Mike needed something to keep people from losing everything whenever their Friendika home node was shut down. So he invented nomadic identity and created the Zot protocol.
Also the same year, Mike forked Free-Friendika into Red (spanish la red = the network). It would be renamed Red Matrix in late 2012 because "Red" is hard to Google.
In 2012, Mike rewrote Red almost completely. The whole backend was rebuilt against Zot.
However, the Red Matrix didn't take off. Most Friendica users were hosting their own private nodes. Nomadic identity made no sense for them. Besides, it seemed like many Friendica users didn't understand nomadic identity anyway, so they saw no advantage in the Red Matrix over Friendica, seeing as the features were almost identical otherwise. The Red Matrix had to be made more popular for hosting public servers.
So in 2015, the Red Matrix was rebuilt and greatly expanded into Hubzilla.
In 2018, Mike wanted to develop the Zot protocol further into Zot6. But this would have meant compatibility-breaking changes, also because what he wanted to do with nomadic identity over Zot6 was likely to not work with non-nomadic protocols anymore. So he couldn't do that on Hubzilla.
Instead, he made two new forks:- first Osada, forked from Hubzilla, which was the original Zot6 development platform and then evolved into a non-nomadic "gateway" between Zot6 and everything else
- then Zap, forked most likely from Osada or maybe from Hubzilla, which got the whole Zot6 feature set, including nomadic identity, but which lost support for any and all non-nomadic protocols
A bit later, Zot6 became compatible enough with non-nomadic protocols. Forwarding content from Zap via Osada to the rest of the Fediverse was clunky anyway, forwarding content from the rest of the Fediverse via Osada to Zap even more so. So Osada was discontinued.
Instead, a new Osada was forked from Zap and got ActivityPub support. This and the branding were the only differences between Osada and Zap.
In 2019, when both Osada and Zap had become stable, Zap got ActivityPub support itself. The only difference between the two was now that Osada servers had ActivityPub turned on by default, and Zap servers had it turned off by default. It simply didn't make much sense to keep both alive, so Osada was discontinued again.
I think it was also in 2019 that Hubzilla was upgraded to Zot6.
In 2020, Mike made three more forks to develop Zot8, at least one of which was forked from Zap, and those that weren't were forked from one another: Redmatrix 2020, Mistpark 2020 a.k.a. Misty and Osada.
There was a rumour that Zap was the stable one, Misty was a bit more up-to-date, but potentially less stable, Osada was experimental with ActivityPub support on by default, and Redmatrix 2020 was experimental with ActivityPub support off by default. In fact, however, Misty, Osada and Redmatrix 2020 were absolutely identical in all but branding. Mike kept four server applications around to mess with brand fetishists.
In 2022, Mike forked one of the three into Roadhouse to develop Zot11. But Zot11 was no longer compatible with Zot6 as implemented on Hubzilla and Zap, so he declared it a new protocol named Nomad. Roadhouse got additional support for Zot6.
Now Mike had five server applications, still in order to mess with brand fetishists.
Later the same year, Mike forked Roadhouse into something intentionally nameless and brandless. Again, this was done to troll brand fetishists, this time also to facilitate forking and make people think up their own individual names for the fork rather than keeping the existing one. However, the code repository absolutely required a name, so Mike called it streams.
The community needed something to name this nameless thing by, so they took the name of the repository and wrapped it in parentheses to make sure that this is not actually the name. Ever since, it is colloquially being called (streams). By the way, (streams) is running on what would be Zot12 if it wasn't Nomad now.
On New Year's Eve 2022, Mike discontinued Zap, Redmatrix 2020, Misty, Osada and Roadhouse. (streams) was stable enough, and the other five could be upgraded not only to each other by rebasing the server code, but also to (streams). He asked all admins of Zap, Redmatrix 2020, Misty, Osada and Roadhouse servers to upgrade to (streams).
In 2024, (streams) got bogged down by some identity confusion after the stable release branch introduced decentralised IDs as per FEP-ef61, a part of the development of nomadic identity via ActivityPub. Partially in order to be able to sort this out, partially because the time seemed to have come for this to actually work, Mike forked the streams repository into Forte and removed all support for any protocols other than ActivityPub while still keeping it nomadic. And so Forte became the very first Fediverse server application that establishes nomadic identity via ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendika #FreeFriendika #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Redmatrix2020 #Mistpark2020 #Misty #Roadhouse #Streams #(streams) #Forte -
@Gaming on the Fediverse That's quite a bit simplified. For one, four server applications and one protocol were lumped together. Besides, Zap is dead, and Forte isn't even mentioned.
So here's an attempt at telling the whole story (server applications are in bold type, protocols are in bold type and italics):
tl;dr:
2010:- DFRN
- Mistpark/Friendika/Friendica
(DFRN)
- Zot
- Free-Friendika
(DFRN)
(forked from Friendika) - several other Friendika forks
(DFRN)
(forked from Friendika)
(discontinued 2011) - Red/Red Matrix
(DFRN, from 2012 Zot)
(forked from Free-Friendika)
(rebuilt into Hubzilla 2015)
- Hubzilla
(Zot, later Zot6)
(rebuilt from the Red Matrix)
- Zot6
- Osada
(Zot6)
(forked from Hubzilla)
(discontinued in 2018) - Zap
(Zot6)
(forked most likely from Osada, maybe from Hubzilla)
(discontinued in 2022) - Osada
(Zot6)
(forked from Zap)
(discontinued in 2019)
- Zot8
- Redmatrix 2020
(Zot8)
(forked from either Zap or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - Mistpark 2020 a.k.a. Misty
(Zot8)
(forked from either Zap or Redmatrix 2020 or (the third) Osada)
(discontinued in 2022) - Osada
(Zot8)
(forked from either Zap or Redmatrix 2020 or Mistpark 2020)
(discontinued in 2022)
- Nomad
(originally Zot11) - Roadhouse
(Nomad)
(forked from either Redmatrix 2020 or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - (streams)
(Nomad)
(forked from Roadhouse)
Forte
(ActivityPub)
(forked from (streams))[/list]
So as far as Fediverse server applications go, he created Friendica, Free-Friendika, a few more Friendika forks, the Red Matrix, Hubzilla, three Osadas, Zap, Redmatrix 2020, Mistpark 2020, Roadhouse, (streams) and Forte. Depending on how you want to count them, that's at least 13 or 14 server applications. Four of these are still being maintained (Friendica by a new team, Hubzilla by another new team, (streams) and Forte by himself).
The long version:
In 2010, he created- the DFRN protocol
- Mistpark (renamed first into Friendika later in 2010 and then into Friendica in 2011)
In 2011, he made several forks of Friendika. The reason was licensing: Friendika was getting quite some attention. As it was under the MIT license, chances were that it was tempting to fork it and turn the fork into a commercial, proprietary, closed-source monolith or something. On the other hand, the GPL in any shape or form would have hindered further development.
So Mike made a number of forks and relicensed all but one: Free-Friendika kept the MIT license and became the main development platform for Friendika. Friendika itself was relicensed under the AGPLv3.
Shortly afterwards, Mike discontinued all forks except Free-Friendika.
The same year, Mike needed something to keep people from losing everything whenever their Friendika home node was shut down. So he invented nomadic identity and created the Zot protocol.
Also the same year, Mike forked Free-Friendika into Red (spanish la red = the network). It would be renamed Red Matrix in late 2012 because "Red" is hard to Google.
In 2012, Mike rewrote Red almost completely. The whole backend was rebuilt against Zot.
However, the Red Matrix didn't take off. Most Friendica users were hosting their own private nodes. Nomadic identity made no sense for them. Besides, it seemed like many Friendica users didn't understand nomadic identity anyway, so they saw no advantage in the Red Matrix over Friendica, seeing as the features were almost identical otherwise. The Red Matrix had to be made more popular for hosting public servers.
So in 2015, the Red Matrix was rebuilt and greatly expanded into Hubzilla.
In 2018, Mike wanted to develop the Zot protocol further into Zot6. But this would have meant compatibility-breaking changes, also because what he wanted to do with nomadic identity over Zot6 was likely to not work with non-nomadic protocols anymore. So he couldn't do that on Hubzilla.
Instead, he made two new forks:- first Osada, forked from Hubzilla, which was the original Zot6 development platform and then evolved into a non-nomadic "gateway" between Zot6 and everything else
- then Zap, forked most likely from Osada or maybe from Hubzilla, which got the whole Zot6 feature set, including nomadic identity, but which lost support for any and all non-nomadic protocols
A bit later, Zot6 became compatible enough with non-nomadic protocols. Forwarding content from Zap via Osada to the rest of the Fediverse was clunky anyway, forwarding content from the rest of the Fediverse via Osada to Zap even more so. So Osada was discontinued.
Instead, a new Osada was forked from Zap and got ActivityPub support. This and the branding were the only differences between Osada and Zap.
In 2019, when both Osada and Zap had become stable, Zap got ActivityPub support itself. The only difference between the two was now that Osada servers had ActivityPub turned on by default, and Zap servers had it turned off by default. It simply didn't make much sense to keep both alive, so Osada was discontinued again.
I think it was also in 2019 that Hubzilla was upgraded to Zot6.
In 2020, Mike made three more forks to develop Zot8, at least one of which was forked from Zap, and those that weren't were forked from one another: Redmatrix 2020, Mistpark 2020 a.k.a. Misty and Osada.
There was a rumour that Zap was the stable one, Misty was a bit more up-to-date, but potentially less stable, Osada was experimental with ActivityPub support on by default, and Redmatrix 2020 was experimental with ActivityPub support off by default. In fact, however, Misty, Osada and Redmatrix 2020 were absolutely identical in all but branding. Mike kept four server applications around to mess with brand fetishists.
In 2022, Mike forked one of the three into Roadhouse to develop Zot11. But Zot11 was no longer compatible with Zot6 as implemented on Hubzilla and Zap, so he declared it a new protocol named Nomad. Roadhouse got additional support for Zot6.
Now Mike had five server applications, still in order to mess with brand fetishists.
Later the same year, Mike forked Roadhouse into something intentionally nameless and brandless. Again, this was done to troll brand fetishists, this time also to facilitate forking and make people think up their own individual names for the fork rather than keeping the existing one. However, the code repository absolutely required a name, so Mike called it streams.
The community needed something to name this nameless thing by, so they took the name of the repository and wrapped it in parentheses to make sure that this is not actually the name. Ever since, it is colloquially being called (streams). By the way, (streams) is running on what would be Zot12 if it wasn't Nomad now.
On New Year's Eve 2022, Mike discontinued Zap, Redmatrix 2020, Misty, Osada and Roadhouse. (streams) was stable enough, and the other five could be upgraded not only to each other by rebasing the server code, but also to (streams). He asked all admins of Zap, Redmatrix 2020, Misty, Osada and Roadhouse servers to upgrade to (streams).
In 2024, (streams) got bogged down by some identity confusion after the stable release branch introduced decentralised IDs as per FEP-ef61, a part of the development of nomadic identity via ActivityPub. Partially in order to be able to sort this out, partially because the time seemed to have come for this to actually work, Mike forked the streams repository into Forte and removed all support for any protocols other than ActivityPub while still keeping it nomadic. And so Forte became the very first Fediverse server application that establishes nomadic identity via ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendika #FreeFriendika #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Redmatrix2020 #Mistpark2020 #Misty #Roadhouse #Streams #(streams) #Forte -
@Gaming on the Fediverse That's quite a bit simplified. For one, four server applications and one protocol were lumped together. Besides, Zap is dead, and Forte isn't even mentioned.
So here's an attempt at telling the whole story (server applications are in bold type, protocols are in bold type and italics):
tl;dr:
2010:- DFRN
- Mistpark/Friendika/Friendica
(DFRN)
- Zot
- Free-Friendika
(DFRN)
(forked from Friendika) - several other Friendika forks
(DFRN)
(forked from Friendika)
(discontinued 2011) - Red/Red Matrix
(DFRN, from 2012 Zot)
(forked from Free-Friendika)
(rebuilt into Hubzilla 2015)
- Hubzilla
(Zot, later Zot6)
(rebuilt from the Red Matrix)
- Zot6
- Osada
(Zot6)
(forked from Hubzilla)
(discontinued in 2018) - Zap
(Zot6)
(forked most likely from Osada, maybe from Hubzilla)
(discontinued in 2022) - Osada
(Zot6)
(forked from Zap)
(discontinued in 2019)
- Zot8
- Redmatrix 2020
(Zot8)
(forked from either Zap or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - Mistpark 2020 a.k.a. Misty
(Zot8)
(forked from either Zap or Redmatrix 2020 or (the third) Osada)
(discontinued in 2022) - Osada
(Zot8)
(forked from either Zap or Redmatrix 2020 or Mistpark 2020)
(discontinued in 2022)
- Nomad
(originally Zot11) - Roadhouse
(Nomad)
(forked from either Redmatrix 2020 or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - (streams)
(Nomad)
(forked from Roadhouse)
Forte
(ActivityPub)
(forked from (streams))[/list]
So as far as Fediverse server applications go, he created Friendica, Free-Friendika, a few more Friendika forks, the Red Matrix, Hubzilla, three Osadas, Zap, Redmatrix 2020, Mistpark 2020, Roadhouse, (streams) and Forte. Depending on how you want to count them, that's at least 13 or 14 server applications. Four of these are still being maintained (Friendica by a new team, Hubzilla by another new team, (streams) and Forte by himself).
The long version:
In 2010, he created- the DFRN protocol
- Mistpark (renamed first into Friendika later in 2010 and then into Friendica in 2011)
In 2011, he made several forks of Friendika. The reason was licensing: Friendika was getting quite some attention. As it was under the MIT license, chances were that it was tempting to fork it and turn the fork into a commercial, proprietary, closed-source monolith or something. On the other hand, the GPL in any shape or form would have hindered further development.
So Mike made a number of forks and relicensed all but one: Free-Friendika kept the MIT license and became the main development platform for Friendika. Friendika itself was relicensed under the AGPLv3.
Shortly afterwards, Mike discontinued all forks except Free-Friendika.
The same year, Mike needed something to keep people from losing everything whenever their Friendika home node was shut down. So he invented nomadic identity and created the Zot protocol.
Also the same year, Mike forked Free-Friendika into Red (spanish la red = the network). It would be renamed Red Matrix in late 2012 because "Red" is hard to Google.
In 2012, Mike rewrote Red almost completely. The whole backend was rebuilt against Zot.
However, the Red Matrix didn't take off. Most Friendica users were hosting their own private nodes. Nomadic identity made no sense for them. Besides, it seemed like many Friendica users didn't understand nomadic identity anyway, so they saw no advantage in the Red Matrix over Friendica, seeing as the features were almost identical otherwise. The Red Matrix had to be made more popular for hosting public servers.
So in 2015, the Red Matrix was rebuilt and greatly expanded into Hubzilla.
In 2018, Mike wanted to develop the Zot protocol further into Zot6. But this would have meant compatibility-breaking changes, also because what he wanted to do with nomadic identity over Zot6 was likely to not work with non-nomadic protocols anymore. So he couldn't do that on Hubzilla.
Instead, he made two new forks:- first Osada, forked from Hubzilla, which was the original Zot6 development platform and then evolved into a non-nomadic "gateway" between Zot6 and everything else
- then Zap, forked most likely from Osada or maybe from Hubzilla, which got the whole Zot6 feature set, including nomadic identity, but which lost support for any and all non-nomadic protocols
A bit later, Zot6 became compatible enough with non-nomadic protocols. Forwarding content from Zap via Osada to the rest of the Fediverse was clunky anyway, forwarding content from the rest of the Fediverse via Osada to Zap even more so. So Osada was discontinued.
Instead, a new Osada was forked from Zap and got ActivityPub support. This and the branding were the only differences between Osada and Zap.
In 2019, when both Osada and Zap had become stable, Zap got ActivityPub support itself. The only difference between the two was now that Osada servers had ActivityPub turned on by default, and Zap servers had it turned off by default. It simply didn't make much sense to keep both alive, so Osada was discontinued again.
I think it was also in 2019 that Hubzilla was upgraded to Zot6.
In 2020, Mike made three more forks to develop Zot8, at least one of which was forked from Zap, and those that weren't were forked from one another: Redmatrix 2020, Mistpark 2020 a.k.a. Misty and Osada.
There was a rumour that Zap was the stable one, Misty was a bit more up-to-date, but potentially less stable, Osada was experimental with ActivityPub support on by default, and Redmatrix 2020 was experimental with ActivityPub support off by default. In fact, however, Misty, Osada and Redmatrix 2020 were absolutely identical in all but branding. Mike kept four server applications around to mess with brand fetishists.
In 2022, Mike forked one of the three into Roadhouse to develop Zot11. But Zot11 was no longer compatible with Zot6 as implemented on Hubzilla and Zap, so he declared it a new protocol named Nomad. Roadhouse got additional support for Zot6.
Now Mike had five server applications, still in order to mess with brand fetishists.
Later the same year, Mike forked Roadhouse into something intentionally nameless and brandless. Again, this was done to troll brand fetishists, this time also to facilitate forking and make people think up their own individual names for the fork rather than keeping the existing one. However, the code repository absolutely required a name, so Mike called it streams.
The community needed something to name this nameless thing by, so they took the name of the repository and wrapped it in parentheses to make sure that this is not actually the name. Ever since, it is colloquially being called (streams). By the way, (streams) is running on what would be Zot12 if it wasn't Nomad now.
On New Year's Eve 2022, Mike discontinued Zap, Redmatrix 2020, Misty, Osada and Roadhouse. (streams) was stable enough, and the other five could be upgraded not only to each other by rebasing the server code, but also to (streams). He asked all admins of Zap, Redmatrix 2020, Misty, Osada and Roadhouse servers to upgrade to (streams).
In 2024, (streams) got bogged down by some identity confusion after the stable release branch introduced decentralised IDs as per FEP-ef61, a part of the development of nomadic identity via ActivityPub. Partially in order to be able to sort this out, partially because the time seemed to have come for this to actually work, Mike forked the streams repository into Forte and removed all support for any protocols other than ActivityPub while still keeping it nomadic. And so Forte became the very first Fediverse server application that establishes nomadic identity via ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendika #FreeFriendika #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Redmatrix2020 #Mistpark2020 #Misty #Roadhouse #Streams #(streams) #Forte -
@Gaming on the Fediverse That's quite a bit simplified. For one, four server applications and one protocol were lumped together. Besides, Zap is dead, and Forte isn't even mentioned.
So here's an attempt at telling the whole story (server applications are in bold type, protocols are in bold type and italics):
tl;dr:
2010:- DFRN
- Mistpark/Friendika/Friendica
(DFRN)
- Zot
- Free-Friendika
(DFRN)
(forked from Friendika) - several other Friendika forks
(DFRN)
(forked from Friendika)
(discontinued 2011) - Red/Red Matrix
(DFRN, from 2012 Zot)
(forked from Free-Friendika)
(rebuilt into Hubzilla 2015)
- Hubzilla
(Zot, later Zot6)
(rebuilt from the Red Matrix)
- Zot6
- Osada
(Zot6)
(forked from Hubzilla)
(discontinued in 2018) - Zap
(Zot6)
(forked most likely from Osada, maybe from Hubzilla)
(discontinued in 2022) - Osada
(Zot6)
(forked from Zap)
(discontinued in 2019)
- Zot8
- Redmatrix 2020
(Zot8)
(forked from either Zap or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - Mistpark 2020 a.k.a. Misty
(Zot8)
(forked from either Zap or Redmatrix 2020 or (the third) Osada)
(discontinued in 2022) - Osada
(Zot8)
(forked from either Zap or Redmatrix 2020 or Mistpark 2020)
(discontinued in 2022)
- Nomad
(originally Zot11) - Roadhouse
(Nomad)
(forked from either Redmatrix 2020 or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - (streams)
(Nomad)
(forked from Roadhouse)
Forte
(ActivityPub)
(forked from (streams))[/list]
So as far as Fediverse server applications go, he created Friendica, Free-Friendika, a few more Friendika forks, the Red Matrix, Hubzilla, three Osadas, Zap, Redmatrix 2020, Mistpark 2020, Roadhouse, (streams) and Forte. Depending on how you want to count them, that's at least 13 or 14 server applications. Four of these are still being maintained (Friendica by a new team, Hubzilla by another new team, (streams) and Forte by himself).
The long version:
In 2010, he created- the DFRN protocol
- Mistpark (renamed first into Friendika later in 2010 and then into Friendica in 2011)
In 2011, he made several forks of Friendika. The reason was licensing: Friendika was getting quite some attention. As it was under the MIT license, chances were that it was tempting to fork it and turn the fork into a commercial, proprietary, closed-source monolith or something. On the other hand, the GPL in any shape or form would have hindered further development.
So Mike made a number of forks and relicensed all but one: Free-Friendika kept the MIT license and became the main development platform for Friendika. Friendika itself was relicensed under the AGPLv3.
Shortly afterwards, Mike discontinued all forks except Free-Friendika.
The same year, Mike needed something to keep people from losing everything whenever their Friendika home node was shut down. So he invented nomadic identity and created the Zot protocol.
Also the same year, Mike forked Free-Friendika into Red (spanish la red = the network). It would be renamed Red Matrix in late 2012 because "Red" is hard to Google.
In 2012, Mike rewrote Red almost completely. The whole backend was rebuilt against Zot.
However, the Red Matrix didn't take off. Most Friendica users were hosting their own private nodes. Nomadic identity made no sense for them. Besides, it seemed like many Friendica users didn't understand nomadic identity anyway, so they saw no advantage in the Red Matrix over Friendica, seeing as the features were almost identical otherwise. The Red Matrix had to be made more popular for hosting public servers.
So in 2015, the Red Matrix was rebuilt and greatly expanded into Hubzilla.
In 2018, Mike wanted to develop the Zot protocol further into Zot6. But this would have meant compatibility-breaking changes, also because what he wanted to do with nomadic identity over Zot6 was likely to not work with non-nomadic protocols anymore. So he couldn't do that on Hubzilla.
Instead, he made two new forks:- first Osada, forked from Hubzilla, which was the original Zot6 development platform and then evolved into a non-nomadic "gateway" between Zot6 and everything else
- then Zap, forked most likely from Osada or maybe from Hubzilla, which got the whole Zot6 feature set, including nomadic identity, but which lost support for any and all non-nomadic protocols
A bit later, Zot6 became compatible enough with non-nomadic protocols. Forwarding content from Zap via Osada to the rest of the Fediverse was clunky anyway, forwarding content from the rest of the Fediverse via Osada to Zap even more so. So Osada was discontinued.
Instead, a new Osada was forked from Zap and got ActivityPub support. This and the branding were the only differences between Osada and Zap.
In 2019, when both Osada and Zap had become stable, Zap got ActivityPub support itself. The only difference between the two was now that Osada servers had ActivityPub turned on by default, and Zap servers had it turned off by default. It simply didn't make much sense to keep both alive, so Osada was discontinued again.
I think it was also in 2019 that Hubzilla was upgraded to Zot6.
In 2020, Mike made three more forks to develop Zot8, at least one of which was forked from Zap, and those that weren't were forked from one another: Redmatrix 2020, Mistpark 2020 a.k.a. Misty and Osada.
There was a rumour that Zap was the stable one, Misty was a bit more up-to-date, but potentially less stable, Osada was experimental with ActivityPub support on by default, and Redmatrix 2020 was experimental with ActivityPub support off by default. In fact, however, Misty, Osada and Redmatrix 2020 were absolutely identical in all but branding. Mike kept four server applications around to mess with brand fetishists.
In 2022, Mike forked one of the three into Roadhouse to develop Zot11. But Zot11 was no longer compatible with Zot6 as implemented on Hubzilla and Zap, so he declared it a new protocol named Nomad. Roadhouse got additional support for Zot6.
Now Mike had five server applications, still in order to mess with brand fetishists.
Later the same year, Mike forked Roadhouse into something intentionally nameless and brandless. Again, this was done to troll brand fetishists, this time also to facilitate forking and make people think up their own individual names for the fork rather than keeping the existing one. However, the code repository absolutely required a name, so Mike called it streams.
The community needed something to name this nameless thing by, so they took the name of the repository and wrapped it in parentheses to make sure that this is not actually the name. Ever since, it is colloquially being called (streams). By the way, (streams) is running on what would be Zot12 if it wasn't Nomad now.
On New Year's Eve 2022, Mike discontinued Zap, Redmatrix 2020, Misty, Osada and Roadhouse. (streams) was stable enough, and the other five could be upgraded not only to each other by rebasing the server code, but also to (streams). He asked all admins of Zap, Redmatrix 2020, Misty, Osada and Roadhouse servers to upgrade to (streams).
In 2024, (streams) got bogged down by some identity confusion after the stable release branch introduced decentralised IDs as per FEP-ef61, a part of the development of nomadic identity via ActivityPub. Partially in order to be able to sort this out, partially because the time seemed to have come for this to actually work, Mike forked the streams repository into Forte and removed all support for any protocols other than ActivityPub while still keeping it nomadic. And so Forte became the very first Fediverse server application that establishes nomadic identity via ActivityPub.
CC: @Grow Fediverse
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendika #FreeFriendika #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Redmatrix2020 #Mistpark2020 #Misty #Roadhouse #Streams #(streams) #Forte -
@jupiter_rowland @growfediverse
Mike Macgirvin is credited for 5 projects on (#)Wikidata:
1️⃣ Friendica (developer)
2️⃣ Hubzilla (dev)
3️⃣ streams (dev)
4️⃣ Zap (dev)
5️⃣ Zot (dev)https://www.wikidata.org/wiki/Special:WhatLinksHere/Q114669840
#Wikidata #MikeMacgirvin #Friendica #Hubzilla #streams #Zap #Zot
-
@jupiter_rowland @growfediverse
Mike Macgirvin is credited for 5 projects on (#)Wikidata:
1️⃣ Friendica (developer)
2️⃣ Hubzilla (dev)
3️⃣ streams (dev)
4️⃣ Zap (dev)
5️⃣ Zot (dev)https://www.wikidata.org/wiki/Special:WhatLinksHere/Q114669840
#Wikidata #MikeMacgirvin #Friendica #Hubzilla #streams #Zap #Zot
-
@jupiter_rowland @growfediverse
Mike Macgirvin is credited for 5 projects on (#)Wikidata:
1️⃣ Friendica (developer)
2️⃣ Hubzilla (dev)
3️⃣ streams (dev)
4️⃣ Zap (dev)
5️⃣ Zot (dev)https://www.wikidata.org/wiki/Special:WhatLinksHere/Q114669840
#Wikidata #MikeMacgirvin #Friendica #Hubzilla #streams #Zap #Zot
