And of course, although it's already in the Lemmy community sidebar:

Join the Fediverse Wiki: https://joinfediverse.wiki

CalcKey should have been renamed ℂ instead of Firefish. Because.

@Squidquid Option #1: Search for a hashtag. If it exists, and it's halfway active, follow it. No, I'm not kidding you, you can do that on Mastodon.

Option #2: the people section on fediverse.info.

Option #3: No matter which instance you're on, go to mastodon.social with your Web browser and search it for interesting hashtags. This may reveal to you more people who are interested in those topics/write about those topics.

Also, if you want to learn more about the Fediverse beyond Lemmy (and beyond Mastodon, for that matter), go follow fediversenews@venera.social. It's a public forum on Friendica. You'll learn soon enough what Friendica is.

@lechatron And I wonder if Musk has the balls to try and buy x.org.

Right now, there's no smoother way.

There will be one when Mastodon introduces support for the single sign-on standard OpenWebAuth that was created along with Hubzilla. I'm not sure how likely this is to actually happen, but it's planned AFAIK.

17

@Fediverse

Again, this post goes out to both the #Threadiverse and the rest of the #Fediverse.

I've decided that only writing about my problems with #AltText and enormous #ImageDescriptions won't work as well as actually demonstrating what I mean, and why it's a problem.

Preamble: Some of you may see me on #Lemmy. But I'm not on Lemmy.

Others may see me in their local or federated timelines on #Mastodon. But I'm not on Mastodon either.

I'm on #Hubzilla (official website) which is part of the Fediverse and federated with Mastodon, Lemmy and just about everything else. It has almost unlimited possibilities. But while I can do a lot here, especially Mastodon is deliberately incapable of displaying most of it.

For example, I can write posts that are tens of thousands of characters long, and I can write alt-texts that are almost as long as the posts can be. But while Mastodon can still show posts from outside unshortened, no matter how long they are, it has a hard cap of only 1,500 characters for alt-text which, as far as I know, is applied to alt-texts on images in posts that come in from outside Mastodon as well.

Also, I can embed as many pictures as I want in Hubzilla posts, and I can actually embed them. I can place them wherever I want in-between the paragraphs. I don't necessarily have to put them at the end. Mastodon, on the other hand, knows pictures only as file attachments which it puts below a toot. And Mastodon toots can only have a maximum of four file attachments.

Lastly, I know that the vast majority of Mastodon users use Mastodon through a dedicated app on a mobile phone. Whenever they tap a link, it will open their Web browser. I also know that mobile Mastodon users tend to see their Web browser popping up as a nuisance, and they'd rather avoid to use their Web browser and experience the Fediverse in its entirety in their Mastodon app without anything else opening.

These are limiting factors, some of which will play a role in this demonstration.

Now, to get to the topic which I've already ranted about here and, most recently, here.

I'm stuck in a situation that's a combination of these factors:

One, the Fediverse demands I comply with its #accessibility requirements at the behest of #blind and #VisuallyImpaired users, otherwise I'll be sanctioned in some way. And I'm not the one to skimp on this. I'd rather try to satisfy everyone's needs. I'd rather have people tell me that what I've done is complete and utter overkill than that what I've done isn't sufficient.

Two, while some are satisfied with a short and concise alt-text, others ask for full descriptions of pictures with everything in them plus explanations for those who are unfamiliar with what's shown in the picture.

To give you an example, here is an actual Mastodon toot from a few weeks ago. I have re-shared this post a few times already, but I can't expect everyone who reads this post to have seen it before. I've used Hubzilla's own built-in standard re-sharing feature to automatically put it here into this post:

----------

Stormgren schrieb den folgenden Beitrag Mon, 03 Jul 2023 18:20:44 +0200

Alt-text doesn't just mean accessibility in terms of low -vision or no-vision end users.

Done right also means accessibility for people who might not know much about your image's subject matter either.

This is especially true for technical topic photos. By accurately describing what's in the picture, you give context to non-technical viewers, or newbies, as to exactly what they're looking at, and even describe how it works or why it matters.

#AltText is not just an alternate description to a visual medium, it's an enhancement for everyone if you do it right.

(So I can't find any prior post of mine on this, so if I've actually made this point before, well, you got to hear a version of it again.)

----------

In case you didn't get a link to the account this post came from and/or to the post itself, here is a link to the post.

Besides, just look through posts with the #AltText tag on them, and you'll see many with very elaborate and detailed descriptions, albeit often of not-so-detailed pictures, but still. So this is actually happening, yes. Not only that, but fully-detailed image descriptions are often actually praised rather than criticised.

Three, alt-text and #ImageDescription rules demand all text in a picture be transcribed in their entirety, word by word.

Four, I often post pictures that, taking the above into consideration, require very extensive descriptions because there's just about absolutely nothing in them which my audience is familiar with. My pictures are usually taken inside a virtual 3-D world based on #OpenSimulator because that's what this Hubzilla channel is mainly about. But out of probably over 13 million Fediverse users, maybe two or three dozen are familiar with #OpenSim worlds in general, and all the others aren't. And I can often hardly expect even three or four of them to be familiar with that particular place where I've taken the picture. Let's say these places are far from being as well-known and as not requiring description or explanation as Times Square, the Eiffel Tower or the Sydney Opera House. And if people don't know something, they need it described.

Five, I don't always post pictures like on Instagram or Pixelfed. That's when you make posts with pictures, and the posts are about the pictures. I sometimes use pictures as illustrations for posts which are not about these pictures specifically. In fact, these pictures are actually optional. Unlike in the former case, full image descriptions in the visual part of the post are bad style in this case.

So much about my situation.

What I'm going to do now is demonstrate multiple ways in which a certain picture that requires a very extensive description can be described in a post. None of them will be perfect. Each one of them will have its shortcomings which I'm sure will discriminate against someone out there.

The image in question can be found through this link. I have deliberately linked to the picture rather than embedded it here in order not to have to provide an alt-text that's sufficiently satisfying for everyone in this post already. The follow-up posts will be about describing this picture. Thus, they will all contain a description of the picture, and at least one of them is very likely to provide a full image description in the post body that should be accessible to everyone on every Fediverse project.

The image was first used in a post from over a year ago (link to the post) in which I've mentioned that the Metropolis Metaversum, one of the oldest OpenSim grids, has finally shut down after 14 years of operation, a few days later than scheduled. The picture shows my Metropolis avatar waving at the camera one last time before the grid, and the avatar with it, comes to its end.

Due to how detailed the picture is, due to how many objects with text on them are in the picture, and due to how almost absolutely nobody who may come across this picture will know anything in it, a full description at a detail level similar to describing a single bird in front of a blurry background plus explanations where explanations are necessary plus a full set of transcriptions can only be enormously long.

In the original post, the picture doesn't have an alt-text.

So what I'm going to do now is create multiple remakes of this post with the same wording and the same hashtags. But this time, I'm employing different techniques from remake to remake to include an alt-text and/or a full image description.

For this purpose, I've taken an image description which I've written several days ago, which already had 10,985 characters. I had actually gone in-world and visited a static memorial copy of the location shown in the picture to describe details that are practically invisible, but still theoretically visible in the picture. I've re-worked this description a bit and and expanded it even further. I've also found pictures of the big black sign behind the tree trunk and managed to transcribe it. As what's written on the panel turned out to be in German, I also had to provide a full translation. The only remaining writings within the scope of the picture that weren't transcribed are all on the Windows "screen" of the laptop on the counter of the info desk which is actually a static texture.

When combined into one paragraph, the description has 13,215 characters now.

The variants I'm going to post:

  • Variant 1: short alt-text that only mentions what matters in the context of the post; no description given at all

  • Variant 2: full image description in the alt-text

  • Variant 3: short alt-text announces image description available through a link; full image description available on a separate page

  • Variant 4: short alt-text announces image description; full image description in the text body of the post itself and fully visibly right away

As you will see, each one of them will have serious drawbacks for Mastodon users, for mobile users, for the people for whom we should all write alt-texts and image descriptions in the first place, sometimes for everyone.

#A11y #Inclusion #InclusionMatters #Inclusivity

20

@Fediverse

This is going out to both the #Threadiverse and, because I can't keep this from happening, the rest of the #Fediverse where I've mentioned this issue before three months earlier.

In brief: I'm still not sure how much #AltText is optimal. And I tend to run into situations in which alt-text that describes everything in a picture will grow longer than any of you could possibly imagine in their wildest dreams.

Here's my situation:

  • I don't have a problem with writing a lot. Unlike most of you, I'm not on a phone. I'm on a desktop computer, and if I'm not, I'm on a laptop. I've always got a full-blown hardware keyboard, and I can touch-type with ten fingers. And I like to rant.

  • I'm on #Hubzilla. This means virtually no limit in post length and especially virtually no limit in alt-text length. The only limiting factor would be how much alt-text the instances where my posts are viewed can display. #Mastodon has a hard cap at 1,500 characters, for example.

  • I'm not the one to skimp on #accessibility rules unless they're technologically impossible for me to follow. I'd rather do too much than too little. This includes full transcriptions of all texts in a picture unless privacy issues speak against it, or unless I've got no way to source the original of a text anymore, and said text in the picture is ineligible even for me. Yes, I transcribe text that's one pixel high if I can get the original.

  • When I post pictures, I don't always post them Instagram/Pixelfed-style, i.e. posts that are about this particular picture. Instead, I often use pictures to illustrate the post. Hubzilla gives me all necessary means to write full-blown blog posts with all bells and whistles as regular posts. Describing a picture in the visible part of a post when the post isn't about the picture is horribly bad style. Doing so when there are multiple pictures in one post, regardless of whether Mastodon puts them in the right places (which it doesn't), is even worse.

  • I usually post pictures taken in #VirtualWorlds. In comparison with pictures taken in real-life, they have a much higher tendency to contain things that need to be described, often to both sighted and blind or visually-impaired users, because they simply don't know them, be it objects, be it locations. It's one thing if a picture was taken on Times Square, and it's something else if a picture was taken in a place of which maybe not even five people in the whole Fediverse even know that it exists. Thus, more text is needed.

Now there are two schools of thoughts when it comes to alt-text.

One: clear and concise alt-text. Only describe what's necessary in the context in which the picture is posted. Screen readers can't handle long alt-texts well. You can't navigate alt-text with most screen readers, i.e. you can't stop it somewhere, rewind it to a certain point and listen to parts of it once more. All you can do is let the screen reader rattle down the whole alt-text in one chunk. If you need to hear it again, you have to hear all of it again.

The obvious downside of this is that most of the content of the image is lost to everyone who isn't sighted, and some is lost to those who can't identify it even by looking at it in that particular picture.

Two: full description of absolutely everything in the picture plus explanation if necessary. Denying non-sighted people the chance to experience everything that's in a picture, and be it through words, can be considered ableist. Also, tiny details that are barely visible in the picture could be described so that sighted people can identify them.

And besides, there's the idea that alt-text can help everyone understand what that is that they see (or don't see) in that picture if they're unfamiliar with them.

As I've said, extensive image descriptions in the visible part of a post may be okay when the post is about the picture, but not when the picture illustrates the post and even less when there's more than one picture illustrating the post.

Yes, this is a thing. Just read what @Stormgren wrote earlier this month.

Stormgren wrote the following post Mon, 03 Jul 2023 18:20:44 +0200

Alt-text doesn't just mean accessibility in terms of low -vision or no-vision end users.

Done right also means accessibility for people who might not know much about your image's subject matter either.

This is especially true for technical topic photos. By accurately describing what's in the picture, you give context to non-technical viewers, or newbies, as to exactly what they're looking at, and even describe how it works or why it matters.

#AltText is not just an alternate description to a visual medium, it's an enhancement for everyone if you do it right.

(So I can't find any prior post of mine on this, so if I've actually made this point before, well, you got to hear a version of it again.)

And I'm actually waiting for Mastodon users to refuse to boost posts that contain pictures with insufficient alt-text. Many refuse to boost posts that contain pictures without alt-text already now.

The obvious downside of it is: "DESCRIBE ALL THE THINGS" + lots and lots and lots of stuff in the picture + just about everything needs to be explained because nobody is familiar with any of it = alt-text the size of a rather long blog post.

I've tried that with this picture (no embedding although I could because reasons). I've written a detailed alt-text. I've spent more than three hours in-world in a preserved, static copy of this place, researching and transcribing text where probably none of you would even know that there's text otherwise. The picture alone wasn't enough of a source for an alt-text that I would have deemed sufficient.

Only description plus some transcriptions: 7,636 characters. Description plus everything transcribed, save for the big black panel in the middle background behind the tree which I couldn't transcribe because it no longer exists in-world, plus translations of everything that isn't English plus everything unfamiliar explained: 10,985 characters. If that panel had still existed in-world, and I could have transcribed it, I might have passed the 12,000-character mark. With an image description.

As I've said, Hubzilla doesn't have a hard cap for alt-text length. In theory, it could handle and probably display alt-texts much longer than this. I don't know how it'd display an alt-text of that size in practice, whether it'd be scrollable, whether it'd have a time-out before anyone could read it fully etc. Mastodon, in the meantime, has the hard cap I've mentioned above which probably also cuts alt-texts coming in from outside. That's where most of my audience is. And screen reader users might have no other choice than to sit through their screen readers rambling down alt-text for more than five minutes in one go, especially if they could get a hold of the original alt-text instead of one cropped at the 1,500-character mark.

Now, even though I'll probably kick off two separate threads, I'd like to read your thoughts about how detailed alt-text should be.

#Accessibility #A11y #Inclusion #Inclusivity #InclusionMatters

Mastodon generally has a problem with

  • everything with more than four pictures in one post (because Mastodon has to convert pictures in a post to file attachments, and it can only attach four files to one post)

  • actually, everything with more than one picture in one post (because the order of the pictures may be reversed, depending on where the post comes from)

  • everything which relies on pictures embedded in the text in specific places (because those pictures converted to file attachments are attached below the post)

Technically, you may be able to view them. But chances are big that Mastodon will mangle them server-side, independently from which app you use on your phone.

So what?

Mastodon was named after a metal band that was named after a furry prehistorical elephant. Fact. Yes, really. No, really. No, I'm not kidding you.

Hubzilla is a "social content management system", so-to-speak. It's actually an absolute feature monster.

It's kind of a derivative of Friendica by Friendica's own developer who also created the protocols that each one of them is based on (DFRN for Friendica, Zot for Hubzilla). It inherited several features from Friendica: Post length is virtually unlimited. Text formatting is supported through BBcode which includes embedding of images and other media within the text, and which has been enhanced further on Hubzilla. Both have supported public groups/forums from the beginning, as well as a public calendar.

Friendica had organisation of contacts in groups before Diaspora*'s aspects (which some think were the first of their kind), let alone Google+'s circles (which everyone else thinks were the first of their kind), but Hubzilla expanded them with privacy features. Generally, Hubzilla has one of the most advanced access/permission control systems in the Fediverse.

Both have built-in file hosting which is also used for embedded images and other media. Instead of your pictures being stored "somewhere", you always know where they are because you've put them there.

Friendica mostly became famous for the many services and protocols it federated with. Diaspora*, OStatus, e-mail, RSS (in both directions), WordPress (with no plug-in in WordPress), Tumblr, Libertree, Twitter (!), even Facebook (!!!) for a few months before Facebook changed its TOS. Hubzilla took most of these connectors over.

Now comes some of what Hubzilla has on top, some of which is optional and has to be activated by the user:

  • WebDAV access for the file space

  • private CardDAV address book (I'm not kidding)

  • an additional system of private CalDAV calendars (yes, separate from the calendar inherited from Friendica)

  • long-form article writing using BBcode (and I'm not talking about posts, this is fully separate and a nice way of showing formatted text with embedded pictures to Mastodon users)

  • a wiki system based on BBcode and Markdown + a bit of HTML, allowing for multiple wikis (I'm still not kidding)

  • a simple webpage engine based on BBcode, Markdown and HTML

That's why Hubzilla is a "social CMS". You can do everything with it and then some, just pick what you need. The official Hubzilla website itself is a Hubzilla channel.

Speaking of which: One major organisational difference between Hubzilla and almost the entire rest of the Fediverse is that your content is not stored in your account. Hubzilla (when it was still young, in development and named Red Matrix) introduced a system of "channels". That's where your content goes.

When you register your first account, you automatically create a channel along with it. The channel is your home, your online identity. The account is only necessary to access the channel. You can have multiple channels on the same account, i.e. multiple fully separate identities with one login, and you can switch between them while logged in. Of course, on top of that, Hubzilla still has Friendica's feature of multiple profiles per channel (per account on Friendica) so that you can show the same identity to different connections in different ways and with different details.

The channel system became necessary for the introduction of another one of Hubzilla's killer features: nomadic identity. This goes way beyond account migration. Essentially, you can have the same channel on multiple hubs. Not independent, disconnected copies, but the exact same channel with the exact same content and even the exact same identity.

It works this way: When you register an account on another hub, and you already have a channel, you can choose to clone that channel to the new hub. Not only does this create an identical copy of your channel with everything in it. It also links the original ("primary instance") and the copy ("clone") together and makes sure they always stay in sync. So whatever happens to change on one instance is mirrored to the other one in near-real-time.

You can basically have as many clones as you want to have. If one instance goes down, the others continue to work. And if you have multiple channels, you can mirror them to separate hubs; you don't have to have all of them on the same hubs.

The ID is derived from the hub which the primary instance is on and includes its domain name. The primary hub can be switched if necessary, for example if your original primary hub will or has shut down. This will also change your ID accordingly. One downside is that you have to re-connect all your non-nomadic bidirectional connections (Mastodon, Lemmy, Diaspora*, Friendica etc.).

Last but not least, another nice feature introduced by Hubzilla is a single sign-on system called OpenWebAuth. When you're logged into any hub on which you have an account, and you visit any other Hubzilla hub or other website that supports OpenWebAuth, your login credentials are recognised, and you're treated like logged into that site, only that you obviously don't have all features you'd have with a local account. So you can post directly onto the "walls" of other Hubzilla channels, regardless of on which hubs they reside, but you can't create a channel without an account. Mastodon is said to plan to introduce OpenWebAuth, too.

There's another Fediverse project with nomadic identity, by the same developer yet again. The result of of a long and somewhat convoluted series of forks from Red Matrix which persisted beyond Hubzilla's stable release as an experimental platform.

The project itself is deliberately, intentionally nameless (!) and brandless. But since the code repository needed a name, it was named Streams. So the project is commonly being referred to as (streams), but most instances don't identify as that; they tend to have individual identifications and logos because these can be customised.

In comparison with Hubzilla, (streams) is cut down a lot, offering only Friendica-level "basics" and external federation only with ActivityPub which, on the other hand, is greatly improved.

The original idea behind (streams) is no longer to have a jack-of-all-trades that has all kinds of features imaginable and unimaginable readily built in for admins and then users to activate. This part of Hubzilla's concept made it rather unfit for specialised hubs because the hub admin first had to remove what was unnecessary.

(streams), on the other hand, is fairly bare-bone, and the idea is that creative admins capable of coding can and shall develop their own additions on top of it, ideally also share them. At the same time, (streams) gained some interesting new features such as additional Markdown and HTML support in posts.

Since (streams) is based on a newer version of Zot, now named Nomad, it federates with Hubzilla quite well, and both understand the other's nomadic features. It's even possible to mirror a Hubzilla channel to (streams) (minus the features that (streams) lacks, of course), but not the other way around.

@Nepenthe My impression is rather that actual nerds are few and far between on Mastodon. It used to be somewhat nerdy in its infancy, but it no longer is. Most people use it through mobile apps on iPhones and think that alternatives to any GAFAM products don't even exist. They don't want to read nerd stuff.

Once a nerd who ends up on Mastodon learns that there are Fediverse projects with way more features, and that Mastodon is actually quite lack-lustre and underequipped, as long as they don't have hundreds or thousands of faithful followers yet, they'll go elsewhere. Akkoma. CalcKey, as it's still being called but not for much longer. Mitra. Friendica.

And the hard-core nerds take the next step and move to someplace with working nomadic identity, namely Hubzilla or (streams). Seriously, Hubzilla has no casual, non-techy normies, and (streams) has even fewer.

Searching the whole Fediverse, literally all of it, 100%, is technically impossible or at least very hard to implement, and if implemented, it'd eat up lots of CPU power and network bandwidth.

It's simply next to impossible for any instance of any Fediverse project, also for any centralised or decentralised dedicated search engine, to know all instances and all content on it without all instances actively pushing their existence, their status and all their content to the search engine in real-time.

A search engine that literally covers all of the Fediverse with no exception has to even know about brand-new instances that have just been started a split-second ago. An instance that's so new doesn't even have any connections into the Fediverse yet, probably no content and only one account, the admin account. (Replace "account" with "channel" on Hubzilla and (streams).)

So if someone spins up a new instance of whatever project, that search feature has to know about that instance immediately before the instance even connects with anything. That is, I'm not sure when that search feature is expected to know about a new Hubzilla hub since ActivityPub is optional per hub and per channel and AFAIK off by default for both: Shall the search feature already know when ActivityPub is still off, and nothing in the Fediverse that isn't Hubzilla or (streams) can connect to it anyway, or shall it only learn about the instance the second that the hub admin turns ActivityPub on?

And when the admin of a new instance puts out a test post to see if it runs as desired, and the instance still isn't connected to any other instance, the search feature would immediately know that test post so you can find it if it's that what you're looking for.

Mind you, Google doesn't know everything on the Internet either.

@_jayrope

  • Make sure the community is not on a Lemmy 0.18.0 instance. That version has a federation bug.

  • Visit the community with your Web browser (which is a given since Hubzilla doesn't have any working client apps).

  • Copy the URL of the community (https://lemmy-instance.tld/c/community) from the address bar.

  • On your Hubzilla instance, go to the Connections page.

  • Click the green + Add button.

  • Paste the copied Lemmy URL into the dialogue that opens then and confirm.

At least this worked for me.

3

@test

Headline 1

Headline 2

Headline 3

Headline 4

Headline 5
Headline 6

Centred

Highlighted

Colour

Multiple-linecode blockwith blank lines
21

@Fediverse

I have a question to all of you who have subscribed to Lemmy groups from Fediverse projects that aren't Lemmy. Who follow Lemmy groups from e.g. #Mastodon, #GlitchSoc, #Pleroma, #Akkoma, #MissKey, what's still called #CalcKey, #FoundKey, #Mitra, #GoToSocial, #Socialhome, #Friendica etc., but also #kbin. And I sincerely hope that I'm not the only subscriber to this entire group who isn't on Lemmy.

My question is: If a Lemmy post contains an image or any other media, can you see it?

I'm on #Hubzilla. And when someone posts something with an image in it, I can see the post, but I can't see the image. When someone posts something with a video in it, I can't see the video either.

I can see images in comments with no problem. But I can't see them in posts.

How about you on Mastodon? Or on CalcKey? Or on /kbin? Or elsewhere?

I'm asking and hoping for replies because I need to find out if the issue is on Lemmy's or on Hubzilla's side so I can file a bug report.

@maegul

On the hashtags, interestingly, when provide one in your post form mastodon, it comes through on lemmy as a link to a search of that hashtag on your mastodon instance. I’m guessing that’s a mastodon thing or maybe an activity pub convention.

This isn't Mastodon-specific. The same happens when I post to Lemmy from Hubzilla.

view more: next ›

jupiter_rowland

joined 1 year ago