jupiter_rowland@hub.netzgemeinde.eu

@Der Pepe (Hubzilla) ⁂

(what exactly is a ‘sensitive domain name’?)

A domain name that looks good as part of your Hubzilla ID on a professional business card that you hand over to business clients or business partners.

A domain name that looks like it's the name of a multi-million-Euro corporation or at least owned by a multi-million-Euro corporation. Not even "Hubzilla" itself does that.

<NAME>.com

<NAME>® is a registered trademark of <NAME> Digital Business Solutions GmbH. All rights reserved.

There's no way to stop unread messages being announced as such and added to the unread counter. Also, there's no way to get rid of the start post and the thread.

There's only thing you can possibly to do reduce the chance of this happening in the future.

Let's suppose you have contacts on Mastodon who really behave like Mastodon users. They boost everything they like. They clutter your stream with tons of uninteresting boost spam. One of the reasons why your unread counter goes to "99+" in no time.

If you want to get rid of that boost spam from certain contacts, do as follows:

• Go to Connections.
• Click on the cogwheel on the navbar, a bit to the right of your channel menu.
• Activate the per-connection filters. They're the only option available.
• Go back to Connections.
• Find the contacts that spam you with boosts.
• Edit each one of them, one by one.
  You'll now find two filter lists, an allowlist and a blocklist, just like for your channel, only that these only affect the content coming in from/through this particular contact.
• Add the following line to the blocklist:
  ?verb == Announce
  This will filter out all boosts/renotes/reposts/repeats from that contact.

@𝓒𝓱𝓻𝓲𝓼 I'm not a coder, so I can't answer this more precisely.

FediDevs was designed to latch onto Mastodon's profile fields, Mastodon's database fields and Mastodon's inner workings.

When enough people begged for it to also support e.g. Misskey, the developers had to add code that would latch onto Misskey's profile fields, Misskey's database fields and Misskey's inner workings.

Same with Pleroma. Same probably with Friendica. And so on.

So if FediDevs wants to support Hubzilla, it would have to dig into Hubzilla, latch onto the profile fields in Hubzilla's public profiles, it would have to latch onto database fields that probably only Hubzilla has, it would have to latch onto Hubzilla's very specific inner workings. And that'd be a whole lot of work because Hubzilla is more different from Mastodon than Misskey is.

Then, and only then, will FediDevs be able to support adding Hubzilla channels to starter packs.

The website is called Fedidevs, but it used to be built against only Mastodon. Not the Mastodon client API, but Mastodon's very specific inner workings.

The issue wasn't just that starter packs only worked on Mastodon. It was also that starter packs could only contain Mastodon accounts, and only Mastodon users were even able to join the site because the technical process of joining explicitly looked for features that are only present on Mastodon and nowhere else.

It was blatantly obvious that the maintainers of this site firmly believed that the Fediverse is only Mastodon when they built it, and that they refused to accept the truth when someone pointed out that there's more to the Fediverse than Mastodon later on.

Eventually, after quite a while of operation, they added specific code for certain Fediverse server applications. They added specific code so that Misskey accounts could be added to starter packs. They added specific code so that Pleroma accounts could be added to starter packs. And so on.

The whole thing is not built against any API, much less against ActivityPub. It's built against the inner workings of specific Fediverse server applications. Changing that would require a complete rewrite of the entire backend.

So in order for Hubzilla channels to be added to starter packs, the FediDevs maintainers would have to add specific code to FediDevs so that it supports Hubzilla channels.

@Harald Eilertsen Very nice!

The sliding toggles are fancy, but confusing even to sighted users who aren't used to Hubzilla.

Allow me to chime in here, everyone.

First of all, accessibility is a basic human right.

There actually are blind or visually-impaired users in the Fediverse, also because they're more welcome here than in the corporate silos.

This also means: Just like alt-texts, a Web UI that works with screen reader software (JAWS, NVDA, VoiceOver, TalkBack, Narrator, Orca etc.) is not just another dumb Mastodon fad.

If activists like @Robert Kingett (who, by the way, is blind, and who has some significant range in the Fediverse) criticise Hubzilla for being unusable, this has to be taken seriously. Even though, admittedly, Hubzilla's Web UI using the Redbasic theme isn't even that friendly towards sighted users.

In my opinion, Hubzilla has two options now.

One, carry on as usually, consider it a Mastodon fad that must under no circumstances be adopted, shrug it off, chase all the blind users away back to Mastodon and eventually be branded utterly ableist.

Two, if that's possible in any way, make the Redbasic-based default Web UI accessible to screen reader users and become one of the currently not exactly many Fediverse server applications that do care for UI accessibility.

The latter explicitly welcomes blind users. The former flips the bird at them, now that the "Hubzilla is inaccessible" cat is out of the bag.

Combine this with Hubzilla's notoriously condescending attitude towards Mastodon (where just about everyone who is blind hangs out because they literally don't have much of a choice), and you get a condescending attitude towards disabled people.

Ideally, at least @Saiwal should do the same with his themes. Even though many hub admins refuse to install them because they were written entirely by AI, especially Solidified appears to make using Hubzilla much easier in general.

I can see many veterans who have come from Facebook or nothing at all to Friendica to Hubzilla, whose contacts are all on Hubzilla, Friendica, (streams) and/or Forte, or who have intentionally left PubCrawl uninstalled, shrug it off. We've never needed accessibility. Even if it comes back to bite Hubzilla because the whole platform is being ostracised, sanctioned or even gradually blocked from lots of other Fediverse servers, they'll say that's no loss. For it's no loss to them.

But they mustn't wonder then how come Hubzilla can't get enough of a foothold in the Fediverse for more people to come over from all that underequipped stuff. Especially if Hubzilla not only ignores, but explicitly rejects accessibility.

And no, third-party add-ons can't fix this. Many Hub admins won't install these either.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Inclusion #A11y #Accessibility

As of Hubzilla 11.4.1, the behaviour seems to have changed.

If you have a chain of criteria with OR (||) between them on the allowlist, only the first and last criteria will pass.

If you have ?body ~= foo || ?body ~= bar || ?body ~= baz as an allowlist line:

• Messages with "foo" will pass
• Messages with "bar" will not pass
• Messages with "baz" will pass"

Likewise, if you have ?body ~= foo || ?body ~= bar || ?body ~= baz || ?body ~= qux || ~body ~= quux as an allowlist line:

• Messages with "foo" will pass
• Messages with "bar" will not pass
• Messages with "baz" will not pass
• Messages with "qux" will not pass
• Messages with "quux" will pass"

Test cases:

        'incl: three criteria with OR, all keywords expected in the body, first one present in the body' => [
            '?body ~= grasshopper || ?body ~= rosencrantz || ?body ~= guildenstern',
            '',
            true
        ],
        'incl: three criteria with OR, all keywords expected in the body, second one present in the body' => [
            '?body ~= rosencrantz || ?body ~= grasshopper || ?body ~= guildenstern',
            '',
            true
        ],
        'incl: three criteria with OR, all keywords expected in the body, last one present in the body' => [
            '?body ~= rosencrantz || ?body ~= guildenstern || ?body ~= grasshopper',
            '',
            true
        ],
        'incl: three criteria with OR, all keywords expected in the body, first one present in the body; excl: item must not be a repeat' => [
            '?body ~= grasshopper || ?body ~= rosencrantz || ?body ~= guildenstern',
            '?verb == Announce',
            true
        ],
        'incl: three criteria with OR, all keywords expected in the body, second one present in the body; excl: item must not be a repeat' => [
            '?body ~= rosencrantz || ?body ~= grasshopper || ?body ~= guildenstern',
            '?verb == Announce',
            true
        ],
        'incl: three criteria with OR, all keywords expected in the body, last one present in the body; excl: item must not be a repeat' => [
            '?body ~= rosencrantz || ?body ~= guildenstern || ?body ~= grasshopper',
            '?verb == Announce',
            true
        ],

The second and the fifth test case should fail, the others should pass.

Here are six test cases for your convenience:

            'incl: two criteria with OR, both keywords in the body' => [
                '?body ~= grasshopper || ?body ~= summer',
                '',
                true
            ],
            'incl: three criteria with OR, all keywords in the body' => [
                '?body ~= grasshopper || ?body ~= summer || ?body ~= ant',
                '',
                true
            ],
            'incl: three criteria with OR, one keyword in the body, one check if the item is public, one check if the item is not a comment' => [
                '?body ~= grasshopper || ?item_private == 0 || ?item_thread_top > 0',
                '',
                true
            ],
            'incl: two criteria with OR, both keywords in the body; excl: item must not be a repeat' => [
                '?body ~= grasshopper || ?body ~= summer',
                '?verb == Announce',
                true
            ],
            'incl: three criteria with OR, all keywords in the body; excl: item must not be a repeat' => [
                '?body ~= grasshopper || ?body ~= summer || ?body ~= ant',
                '?verb == Announce',
                true
            ],
            'incl: three criteria with OR, one keyword in the body, one check if the item is public, one check if the item is not a comment; excl: item must not be a repeat' => [
                '?body ~= grasshopper || ?item_private == 0 || ?item_thread_top > 0',
                '?verb == Announce',
                true
            ],

As of now, due to the bug, only the first and the fourth test case will pass because they only have two criteria linked with || in incl. The second, third, fifth and sixth one will fail because they've got more than two criteria linked with || in incl.

@citc In order for someone to post to the forum channel, they must be connected to the channel, i.e. a member of the forum.

Now, you may consider this a severe design flaw because it goes against your idea of how things must work. But this is the best way by far for forum admins to have control over who can do what in the forum.

I mean, how many classic Internet forums allow outsiders to post and comment? Does Reddit allow that? Does Hacker News allow that? Does Slashdot allow that?

No, they don't. None of them do. They all only allow members to post. Because allowing non-members to post would give them next to no control over how to keep certain people from posting.

And no, Superblock is not a solution either.

Don't be too surprised if you do receive these posts in a few hours or days or so.

Sometimes there are unexplicable delays...

@Jakub Urbanowicz Keep that account. At the very least, you'll need somewhere to clone to.

Yup, you have the registration option on the login form, you even have the registration form, but you get a pop-up that tells you that registration is closed.

At the same time, registration on @Der Pepe (Hubzilla) ⁂'s server is open, but nodeinfo seems to say otherwise.

If the one (streams) server that I'm on wasn't currently offline (I hope it'll come back because I've got no clones), I could check which Forte servers it knows, for it seems to know half the Fediverse.

@Jakub Urbanowicz That's weird.

https://forte.fediverse.observer/list (yes, this exists) only lists one server with open registration, and that's one that you haven't found yet.

Either the servers you've found actually don't have open registration, but they still have the option on the login form. Or it's nodeinfo spurting nonsense when it isn't supposed to.

@Der Pepe (Hubzilla) ⁂ In a sense, the same applies to (streams)' post-FEP-ef61 nomadic identity.

I've managed to clone a few (streams) channels, but all my (streams) accounts are pre-FEP-ef61. Most accounts registered post-FEP-ef61 were registered into a (streams) ecosystem that barely offered any servers to clone to.

I guess that (streams) and Forte have fewer than 50 users combined, most of whom run their own private servers for exactly one user and with probably exactly one or two channels, depending on whether or not they daily-drive the admin channel.

What's really standing in the way of both testing nomadic identity on (streams) and Forte and for either to succeed is the lack of people willing and able to run public servers with open registration, regardless of how big these servers will be. Not just set them up, keep them running and peek in every three to six months, but actually pay attention to them and keep them well-maintained.

But then again, we've only got a small handful of such people on Hubzilla. Not many beyond Mark and you, which is why Mark holds most of Hubzilla on his two hubs. And because Scott doesn't really get his planned hubs going, even Americans join Mark's two German hubs.

Vice versa, if a German wants to try out (streams), they may have to join Waitman's American server. Ping times from hell included.

Nomadic identity as a whole is a purely theoretical construct as long as you've got nowhere to clone to.

@Jakub Urbanowicz Mastodon users would cheer if they got nomadic identity. Maybe unless it made things significantly more difficult for them because their identity was channelised.

Mastodon developers, however, would only implement nomadic identity under pressure, if at all. That pressure would be most of the rest of the Fediverse being nomadic and at least one nomadic microblogging/social networking application offering a fairly easy import of Mastodon accounts.

They would only implement nomadic identity if people started running away from Mastodon because it doesn't have nomadic identity. In all other cases, they'd refuse to implement it, at least pan-Fediverse nomadic identity, out of fear that Mastodon users would run away from Mastodon because it's so easy now. If anything, they'd implement nomadic identity in a way that still makes it impossible to move or clone from Mastodon to elsewhere.

But they probably wouldn't implement it if they didn't have to. After all, they refused to implement client-side OpenWebAuth support as well. There's literally a merge request on Mastodon's GitHub that'd implement client-side OpenWebAuth support, and that has been lingering since 2023, completely ignored by the devs. Back then, one merge would have been sufficient to give Mastodon client-side OpenWebAuth support.

So much about whether the Mastodon devs are willing to implement something that Mike Macgirvin has invented. Especially if they can't sell it to their faithful followers as their own original invention, and if they can't sell it to their faithful followers without admitting that there's something else than Mastodon out there in the Fediverse.

But even if Mastodon's devs wanted to implement full server-side nomadic identity, that doesn't mean it'll be easy. Basically, large parts of Mastodon's server backend would have to be rewritten. I guess this is why silverpill threw in the towel, gave up trying to implement nomadic identity on Mitra server-side and built a nomadic client instead.

There is no case of Hubzilla-level nomadic identity having been implemented in non-nomadic, ActivityPub-only, login-equals-identity Fediverse software after the fact. And there won't be any for quite a while.

@Jakub Urbanowicz Forte literally is (streams) without Nomad and Zot6.

I was there when Mike created Forte. I saw why Mike created Forte. I felt the consequences of why Mike created Forte. And I was one of Mike's contacts.

Ca. 2023

Mike got into contact with silverpill who wanted to make Mitra every bit as nomadic as Hubzilla and (streams), but only using ActivityPub. Both figured out that this was actually doable, as in, that even something like (streams) could one day be re-based on ActivityPub.

Mike started dreaming of a nomadic Fediverse in which everything could be cloned to everything.

He created a "nomadic" branch of the streams repository for research and development purposes.

Around early 2024

One key element for nomadic identity via ActivityPub was to have server-independent, decentralised Fediverse identities. These, however, would have to be up front. Thus, FEP-ef61 "Portable Objects" was created.

Both Mike and silverpill started implementing it; Mike did so in already nomadic software, namely the "nomadic" branch of the streams repository.

Channels created on accounts that were registered before (streams) supported FEP-ef61 would continue to use the old IDs internally, but decentralised IDs outward.

June, 2024

Mike was confident enough in the "nomadic" branch which worked reasonably well from his perspective. So he merged the "nomadic" branch into the normal "dev" branch.

July, 2024

I created a new (streams) account with two channels.

Shortly after, Mike merged the "dev" branch into the "release" branch. This caused decentralised IDs as per FEP-ef61 to be rolled out to production servers.

But what had worked under controlled lab conditions completely blew up in the real world: (streams) channels on accounts that were registered before FEP-ef61 did not properly federate with anything anymore, mine included. Content wasn't delivered anywhere anymore, not even within (streams). Mike had no idea at first what had happened.

August, 2024

Mike had figured out that (streams) had to juggle so many different IDs that it had started confusing them. He had to sort out the mess.

Mid-August, 2024

Mike announced the creation of Forte in a restricted message to his contacts. He had basically taken (streams) and ripped out any and all Nomad and Zot6 support to get at least some IDs out of the way so he could fix the bug.

Nonetheless, Forte was fully nomadic at this point.

The other reason why Mike had created Forte was because he had learned that it was foolish in today's Mastodon-dominated Fediverse to deprive (streams) of a name, a brand identity, an actual license and nodeinfo code. The latter had made it next to impossible to find (streams) servers.

Late August, 2024

(streams) had started working again. Everyone was relieved.

But Mike was burned out. In another restricted message to his contacts, he announced his retirement from Fediverse software development, effective August 31st, 2024. (streams) and Forte were up for grabs.

September, 2024

Nobody was found who could continue. Waitman Gobble said he'd like to, and he could, but he had no time. Bill Statler said he'd like to, and he had the time, but he didn't know how to code.

So Mike had to carry on, but at a slower pace.

Mid-September 2024

Mike officially announced the existence of Forte in public as opposed to only to his bubble. He would not have done that if Forte hadn't been fully nomadic.

From what I've read, limitations of ActivityPub kept Forte from real-time syncing, so a timer had to be used to trigger the syncing.

April, 2025

Mike publicly announced the first stable relase of Forte. Apparently, at this point, Forte was capable of real-time syncing, i.e. of syncs being triggered by changes in the channel rather than by a timer.

The only limitations now was that it wasn't possible to move or sync between Forte and something else due to how different other nomadic Fediverse software is, and that Forte didn't have an ActivityPub switch as a last-resort anti-Mastodon drawbridge anymore.

Forte doesn't even support the Nomad protocol or any protocol other than ActivityPub.

Basically, Forte is (streams) without Nomad and Zot6 support and a few other minor differences which elude me right now.

(streams) is Hubzilla

• with easier permission handling
• with four channel types for groups that partially provide features absent from Hubzilla (moderated posts for certain members, permitting vs not permitting members to upload content to the group channel)
• with better comment control
• with OCAP override permanently on
• with an even higher character limit
• with Markdown and HTML available for formatting messages
• with summaries in comments that actually work as Mastodon CWs
• with multiple profiles per channel
• able to verify external identities
• with easier alt-text support (alt-text field in the Photo app)
• able to block entire servers at channel level
• able to block entire server applications (e.g. Threads, Mastodon) at admin level
• with ActivityPub built into the core and on by default
• understanding decentralised identities as per FEP-ef61
• optionally able to receive entire conversations around comments made by contacts

but

• without diaspora* support
• without an RSS/Atom aggregator
• without crossposters to Dreamwidth, Libertree, LiveJournal and WordPress
• without articles
• without planning cards
• without wikis
• without webpages
• without OpenStreetMap support
• without a QR code generator
• without support for the CalDAV calendar in the event calendar frontend
• without modern third-party themes like AdminLTE or Solidified (for now)

(@Everyone: Can you please refrain from repeating my forum comments to your Mastodon followers? I'm commenting here without safeguards.)