jupiter_rowland

@jupiter_rowland@hub.netzgemeinde.eu

• ⁨Comment⁩ on ⁨⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:
  @Chris Trottier Should be doable as a third-party Friendica add-on or Hubzilla app. Both already "federate" with e-mail anyway.
  
  Since it's only out-bound anyway, it should be possible as a third-party (streams) app as well.
  
  #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Friendica #Hubzilla #Streams #(streams)
• ⁨Comment⁩ on ⁨⁩ ⁨⁨4⁩ ⁨weeks⁩ ago⁩:
  @Chris Trottier As I wrote earlier this year:
  
  Someone somewhere out there probably starts their Pleroma instance with:
  
  

  LOAD"PLER*",8,1
  RUN

  
  It's that lightweight.
  
  #Pleroma #C64
• ⁨Comment⁩ on ⁨⁩ ⁨⁨4⁩ ⁨weeks⁩ ago⁩:
  @Scott M. Stolz Okay, if a new setting comes, there should not be a switch in this case. An agreed-upon standard is an agreed-upon standard that shouldn't be overridden by a user option, and I'm certain that whatever will be decided upon will be the best solution from a technical rather than inter-project political point of view.
• ⁨Comment⁩ on ⁨Hubzilla 9.0 Released!⁩ ⁨⁨4⁩ ⁨weeks⁩ ago⁩:
  @Mario Vavti Feature request: Make it four switches instead of one.
  
  One for posts/DMs with a title, regardless of summary.
  One for posts/DMs with a summary.
  One for posts/DMs without either.
  One for comments.
  
  In fact, the last two could be ditched altogether. But at least the first one would mimick how Friendica does things (with title = Article-type, with no title = Note-type). And it absolutely makes sense to send long, blog-style posts as Article-type objects and have Mastodon only show the title, the summary, a link to the original and the hashtags.
  
  In fact, Mastodon's handling of Article-type objects is most likely not a bug but fully intentional. And I'd really like Hubzilla to support it. Just not always.
  
  #Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Hubzilla
• Submitted ⁨⁨4⁩ ⁨weeks⁩ ago⁩ to ⁨fediversenews@venera.social⁩ | ⁨0⁩ ⁨comments⁩
• Submitted ⁨⁨4⁩ ⁨weeks⁩ ago⁩ to ⁨fediversenews@venera.social⁩ | ⁨3⁩ ⁨comments⁩
• Submitted ⁨⁨5⁩ ⁨weeks⁩ ago⁩ to ⁨fediversenews@venera.social⁩ | ⁨0⁩ ⁨comments⁩
• ⁨Comment⁩ on ⁨⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:
  @Chris Trottier @ch0ccyra1n :she_her: Also since Mastodon doesn't know yet what groups are, and Mastodon still refuses to show what project a post came from.
  
  And I guess the majority of Mastodon users don't even know that groups exist in the Fediverse outside maybe Guppe. So it's easy to assume that Fediverse News is a person with a Mastodon account.
  
  #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Groups
• ⁨Comment⁩ on ⁨⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:
  @maegul What'd be more interesting is not only how many of all Fediverse users are FediPact proponents, but also how many are opponents, how many don't care, and above all, how many have never even heard of it. You can't expect someone who has just come over from 𝕏 to mastodon.social to have an opinion on this.
  
  Also, different projects, different opinions. I estimate 10% of all Mastodon users would even love to defederate from everything else in the Fediverse that isn't Mastodon because it's so non-Mastodon, and it does freaky stuff that shouldn't exist on Mastodon. At the same time, a large percentage of Friendica users is probably in favour of federating with Threads because Friendica's concept and culture has been about connectivity with everything that moves and then some since 2010.
  
  #Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Friendica #Threads #FediPact
• ⁨Comment⁩ on ⁨⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:
  @Kristian Speaking :hatt: And since this is limited to the official Mastodon app and then the default Mastodon Web UI, the whole rest of the Fediverse won't even notice and will be able to carry on as usual.
  
  (Disclaimer: I've read this post here on Hubzilla because it was forwarded to me by the Friendica forum Fediverse News. But technically speaking, what I'm doing right now is almost exactly what this new development aims to prevent.)
• My thoughts on Threads
  Submitted ⁨⁨9⁩ ⁨months⁩ ago⁩ to ⁨fediversenews@venera.social⁩ | ⁨2⁩ ⁨comments⁩
• ⁨Comment⁩ on ⁨⁩ ⁨⁨9⁩ ⁨months⁩ ago⁩:
  @Tokyo Outsider (337ppm) No, it was just an idea of mine.
  
  But I guess that Bluesky itself won't develop its own ActivityPub federation, so everything would have to be done by those projects that desire to federate with Bluesky for one reason or another.
• ⁨Comment⁩ on ⁨⁩ ⁨⁨9⁩ ⁨months⁩ ago⁩:
  @Chris Trottier Food for thought because I haven't seen anyone mention this yet:
  
  This means that #Bluesky will be able to federate with #Threads a.k.a. #Barcelona a.k.a. #P92.
  
  Dis gon b gud. /me grabs a folding chair and a bag of popcorn.
• ⁨Comment⁩ on ⁨⁩ ⁨⁨10⁩ ⁨months⁩ ago⁩:
  @maegul So instead of another full-blown Web application running on a Web server next to one or multiple Fediverse project instances, this could theoretically be covered by a library plugin for something that runs on the Web server anyway. Same way as tying e.g. ImageMagick or various SQL databases into Web applications. PHP comes to mind, but then there'd also have to be one for Ruby-on-Rails.
• ⁨Comment⁩ on ⁨⁩ ⁨⁨10⁩ ⁨months⁩ ago⁩:
  @Jens Ljungkvist :mastodon: It isn't necessary to consume it. If you only want to consume it, you can follow anything and everything from Mastodon, only with the limitations that Mastodon is incapable of showing certain elements:
  

  • quotes
    
  • text formatting (bold type, italics, underline, inline code, code blocks)
    
  • advanced text formatting (headlines, bullet-point lists, numbered lists, tables, variable text sizes, superscript/subscript etc.)
    
  • more than four images in one post
    
  • images embedded between text blocks

  
  If you want to see all this properly, you still only need one account on one instance of one project that supports all this. In fact, if you move from Mastodon to CalcKey entirely, that should cover almost everything, and you still only need exactly one login.
  
  But I've seen people wish for "one account for everywhere in the Fediverse" so so many times over the last weeks and months, and I can't help but assume that they always want all capabilities of logged-in users on each instance of each project.
• ⁨Comment⁩ on ⁨⁩ ⁨⁨10⁩ ⁨months⁩ 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.
• ⁨Comment⁩ on ⁨⁩ ⁨⁨10⁩ ⁨months⁩ 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 nginx or 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.