@kainoa @atomicpoet @fediversenews@venera.social kind of an interesting thought. As the fediverse grows you could format pixelfed posts different than Lemmy posts and Funkwhale posts and so on!
kainoa@calckey.social 1 year ago
@atomicpoet @fediversenews@venera.social It's actually been there even since Misskey. An underutilized feature for sure but not anything new.
box464@calckey.social 1 year ago
maegul@calckey.social 1 year ago
@box464 @kainoa @atomicpoet @fediversenews@venera.social
I’ve been saying it for a while … it feels like the fediverse could do with a tool like pandoc but for platform posts, available more or less in the same way language translations are.
It would have to be third party, which is good, as the fediverse could benefit from more platform generic software rather than everyone reinventing the wheel.jupiter_rowland@hub.netzgemeinde.eu 1 year ago
@maegul @Jeff Sikes @Kainoa @Chris Trottier This would have to happen on the server side. And this, in turn, would work the best if it happened directly on the instance servers, and if it was part of the #Fediverse projects themselves.
We've seen what happens when you rely on a third party. It tends to lean towards something centralised, either because someone deliberately only designs a centralised service for it, e.g. #Mastodon full-text search, or because nobody but the devs can be bothered to run an instance, e.g. #Guppe.
Also, decentralised third-party services will have to be connected to Fediverse instances by the admins manually because the admins will have to decide which instance to connect. Many admins won't take that step at all because they've stopped reading the manual the very moment their instance started working reasonably well, and so they don't even know that they have to connect to such a service.
That said, the Fediverse already speaks one common formatting language, and that's #RichText. #CalcKey translates the #Markdown in out-going messages to Rich Text. #Hubzilla translates the #BBcode in out-going messages to Rich Text. #Streams translates Markdown, BBcode and #HTML to Rich Text. And so forth.
Also, translation between message formats will remain half-useless as long as certain projects show a severe lack of capabilities of displaying messages, and this won't change anytime soon, if ever.
Like it or not, #Mastodon fans, but Mastodon is the worst offender. It can't have more than four images in one post, and it can't embed images within the text. All stuff that has been possible on projects older than Mastodon even before there was Mastodon.
On #Hubzilla (and not only there, but just to take one example), I can design any regular message like a blog post:Text block 1
Image 1
Text block 2
Image 2
Text block 3
Image 3
Text block 4
Image 4
Text block 5
Image 5
Text block 6
Image 6
Text block 7
Image 7
Text block 8
Image 8
Text block 9
This is perfectly normal. And this is perfectly legit. #Friendica, Hubzilla and #Streams were deliberately designed to make this possible. And while Hubzilla has an optional extra functionality for long-form articles, Friendica and (streams) only have this one way of long-form posting. So, again, this is normal and legit and intentional.
On Mastodon, however, the very same post looks like this:Text block 1
Text block 2
Text block 3
Text block 4
Text block 5
Text block 6
Text block 7
Text block 8
Text block 9
Image 8 | Image 7
Image 6 | Image 5
The images are ripped out of their context, reversed in their order, and only four even make it into what Mastodon displays.
The only thing a "translator" could possibly do here is put the images in the correct order. Still, only four would make it onto Mastodon timelines due to Mastodon's limitations, only that it'll be the first four instead of the last four. And also due to Mastodon's limitations, they will still end up after the end of the post instead of embedded between text blocks where they belong.
In the opposite direction, from Mastodon to Hubzilla, a "translator" could be a bit more useful. Currently, when a Mastodon toot with multiple images appears on Hubzilla, the images are put ahead of the text and in reverse order. What the "translator" could do (unless Hubzilla introduces that first) is embed the images at the end of the post in "reverse reverse" order. I'd suggest to also resize them (non-destructively; Hubzilla does that by default with its own images) so that four of them can be shown in a 2x2 arrangement just like on Mastodon, but on Hubzilla, that would cost them the alt-text.maegul@calckey.social 1 year ago
@jupiter_rowland@hub.netzgemeinde.eu server side yes, but developed apart from the platforms and optionally included on either a platform or instance basis.
I’m invoking pandoc as a model because they take pride in supporting as many formats as possible and have adopted an all-to-all design that reduces all formats to a single common abstract spec.
jens@toots.nu 1 year ago
@box464 @kainoa @atomicpoet @fediversenews
Yes!
I already follow “other” ActivityPub accounts from Mastodon.
When there are so many projects you kind of want to set them all up, but on the other end, then you’ll need sooo many accounts to handle it.
If we can “unify” services into single accounts, I think that could be a killer feature. Like I’d be getting Tweets, insta photos and posts from Reddit or a blog all in the same timeline together with music from the artists I follow.jupiter_rowland@hub.netzgemeinde.eu 1 year ago
@Jens Ljungkvist :mastodon: @Jeff Sikes @Kainoa @Chris Trottier Something similar to "one account on all projects" is already in the works.
By and by, #Fediverse projects may adopt #OpenWebAuth, a #SingleSignOn implementation developed by @mike for #Hubzilla and currently implemented on Hubzilla, its direct predecessor #Friendica and its latest not-quite direct descendant, #Streams. An implementation is also in development on #Mastodon. It should not be confused with #OAuth and #OAuth2, these are something entirely different.
What OpenWebAuth is that it recognises logins elsewhere. When I'm logged into this Hubzilla account, and I visit another Hubzilla hub or maybe a Friendica node or a (streams) instance, it will automatically recognise me. And it will grant me some extra "guest permissions" like being able to post directly on the wall of another Hubzilla or (streams) channel.
What it does not do, however, is give me all the power on any Friendica node, Hubzilla hub or (streams) instance that a logged-in user with a user account has.
I can't go to another Hubzilla hub and create a clone of my channel or create a brand-new channel or post an article or start a wiki or upload files just with my OpenWebAuth login credentials. And when Mastodon introduces OpenWebAuth, I still won't be able to go to any one random Mastodon instance and start tooting. All this would still require a local user account on that one specific instance.
One account for the whole Fediverse is utopic. It's technologically impossible or just very very very unfeasible.
The Fediverse has 24,000+ instances of dozens of projects. If you want full local user power everywhere in the Fediverse, you'll need one registered account on each one of these 24,000+ instances.
Whenever someone joins mastodon.social, then RATATATATATATATATATATA, 24,000+ more accounts with the same login credentials will have to be created automatically.
Also, the Fediverse has 12,000,000+ users. If you want full local user power everywhere in the Fediverse, then everyone else must have it, too. So every single instance of each Fediverse project will have to have one account per Fediverse user. The only exceptions would be those very few projects which are designed for only one user account.
However, personal instances of projects that are designed for multiple user accounts will all be affected. The hapless Mastodon user who comes over to your personal Hubzilla hub to act like a registered user will neither know nor care if that hub is running on a root server in a data centre with two 36-core Xeon CPUs and enough RAM to make a 3-D CAD workstation cry or on a Raspberry Pi at your home.
Now, let's assume someone has set up a new Web server with some Fediverse project installed on it. It doesn't matter if that's Mastodon or #CalcKey or #Lemmy or #Mitra or (streams) or whatever as long as it has #ActivityPub. They start that thing up for the first time:sudo systemctl start nginxor so.
And RATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA, that poor thing will sit for WEEKS registering over twelve million user accounts.
Why? Because anyone in the Fediverse might come over anytime soon and want to use just this one specific instance as if they had registered their personal user account there. In order to be able to do that, they need a user account.
By the way, not even the notorious featherweight #Pleroma could handle 12,000,000+ user accounts on one instance. Mastodon can do that even less, not to mention the heavyweight Friendica or the super-heavyweight Hubzilla.
Speaking of Hubzilla, maybe a new Hubzilla hub might get away more easily when starting up for the first time. On Hubzilla, ActivityPub is optional per hub and then per channel. The hub admin can switch it on and off, and if it's on, the users can switch it on and off again for each one of their channels.
So if ActivityPub is off on the admin side by default, new Hubzilla hubs will only register one user account for each Hubzilla and (streams) user out there, maybe also for the users on the few remaining instances of the #Zotlabs projects that went EOL on New Year's Eve 2022, #Redmatrix, #Osada, #Zap, #Misty a.k.a. #Mistpark2020 and #Roadhouse. They all speak one native language, #Zot.
But once the admin activates the Pubcrawl app for their hub, that hub will immediately start registering user accounts for every user on every instance of every project that connects to Hubzilla via ActivityPub, each account with one channel with Pubcrawl on. And it will spend weeks or months doing so and not have any server resources left to do anything else in the meantime.
Speaking of Hubzilla, there's also #NomadicIdentity, the killer feature of the Zot protocol. Hubzilla has it, (streams) has it, and the (un)dead Zotlabs projects have it.
Ideally, each Fediverse user would not get one account on each Hubzilla hub and each (streams) instance with one separate, unique channel on it. They would first get the accounts. On one account on one Hubzilla hub, one channel would be created. This channel would then be cloned across all Hubzilla hubs and to (streams).
Advantage: Each Fediverse user would only have one channel for Hubzilla and (streams) together. They would have the exact same content on all Hubzilla hubs and, minus what Hubzilla can do that (streams) can't, all (streams) instances.
Obvious disadvantage: Whenever someone decides to do something on that channel, it would have to be synced to all its clones in near-real-time, causing a lot of network traffic.
And if you set up a new Hubzilla hub or (streams) instance, the creation of 12,000,000+ accounts would actually become a lesser problem. The bigger problem would be the 12,000,000+ channels that will be cloned onto your machine with everything on them. You'd better attach a few petabytes worth of HDD capacities to your personal little Raspberry Pi.
By the way, if everyone had full local user rights on each Fediverse instance, the Fediverse would have over 300 billion local accounts.jens@toots.nu 1 year ago
That post was A LOT to digest. It will take me a while. My first thought is to wonder if having accounts on all instances is necessary to consume the content? In my example I talked about bringing content into my home feed. So at first it’s a matter of forming the content to be viewed in the current context. I’m struggling to understand why that would need every account on every instance. I need to read your post some more.
fyrfli@bkgrdclrschm.link 1 year ago
@kainoa@calckey.social @atomicpoet@calckey.social @fediversenews@venera.social huh ... never noticed it in use. all twitter links have forced me to click offsite.