𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

       🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆. 
 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍 
  • 0 Posts
  • 11 Comments
Joined 2 years ago
cake
Cake day: August 26th, 2022

help-circle
  • But control of the protocol - the definition and development - is still controlled by the for-profit company, right? It hasn’t been handed over to a nonprofit governance committee, has it?

    Federation or not, if Bluesky dominates the protocol, they can decide to stop federating and essentially kill the independent servers. Much like what Signal did. Sure, you can run your own Signal server, but without access to the dominant player’s market, and using a protocol that’s controlled monopolistically, it’s practically useless to do so - which is why almost nobody does it anymore.


  • I really like the Nostr protocol, though. It’s too bad the network is so inundated by cryptocurrency topics.

    It’s simple, it has a nice extension process (standing on the shoulders of giants), and it’s super easy and lightweight to self-host. It reminds me a lot of the early days of http, when it was more common (as a developer) to telnet to port 80 and just type in a couple of lines of header and get a response.

    Sadly, Nostr’s association with cryptocurrency, and the fact that 90% of the traffic on it is cryptocurrency created posts, has been a severe handicap.




  • What op said still stands: if only one of your users follow a high-traffic, heavy-content /c/, then the server is caching all of that content for one person.

    E.g., there’s this great bot on Mastodon that posts random fractals, and the highest-voted ones “breed” to create a new generation of child fractals. The bot posts a static image and an animated movie of each new child every 4 hours. The images are ca 5mb each; the movies are between 20 & 40mb ea. That is, on average, 210mb/d, or 1.4gb per week. That’s a lot of data. You might, as an admin offering a free service, not want to have to pay for that much storage just because one or two users are suscribed to /c/flamereactor (“FlameReactor” is the name, so you can find this mind-blowingly awesome bot). There’s also bandwidth considerations, both on the pull and when users request the content.

    I like the idea, though, and will suggest a tweak, tried and true from Usenet days: provide the ability to unblock to only paying users. It’d give admins control, plus money to offset storage costs. Maybe provide three options to admins: full defederation; auto-block with any user able to unblock, for odeous but low impact sices; and auto-block with unblock for only users in some group - close friends, paying users, whatever.

    Lemmy could also transcribe content into links back to the source, but that’s just punting the bandwidth costs onto someone else, and I wouldn’t be surprised if this is frowned upon within The Federation (although it’s common practice with Reddit and X(twitter) content).


  • The Fediverse in general needs federated identities, preferrably self-sovereign. Something like nostr, with validation signatures. E.g., you own your ID, and validate it with some mechanism of your preference. If midwest.social trusts your validator, it creates a space for your ID.

    I don’t think this is conceptually or implementationally difficult, but it would require a well written standard and consider both privacy issues (for users) and protections against spammers and bad actors (for hosting providers). I don’t thing PGP’s web-of-trust model would be a bad one. I think using the nostr network (quasi online chain) would be a great idea, and all of the parts are there; it would need a decent UI and support in each Fedi server implementation - which would be the biggest hurdle.

    This would address the DID issue, and I agree with you that this is issue #1. Right now, users don’t own their identities: their hosting service does. If midwest.social chose to, they could nuke my account and the canonical source of truth for all my posts. I run my own ActivityPub server and so own the account I use for Mastodon; and, perhaps, someday Fediverse federation will evolve to the point where I can use that account for everything. But it’s an expensive node for me to operate, and not everyone can run their own server. Better, self-sovereign, and truly federated DIDs is incredibly important.



  • I think it comes down to: when we’re dealing with truly non-technical users, we hope the clients have some sort of UI to insert codes; very non-tech users aren’t going to be very handy with any markup, and the best thing for them is some sort of WYSIWYG interface, or at very least an “insert markup buttons” feature.

    For the people writing markup by hand, IMO markup that minimally interferes with reading when it is unline (unrendered) is best. HTML, BBCode, and other heavy markup gets in the way more than (e.g.) djot, asciidoc, markdown, and other languages that descend from intuitively evolved markup from 70’s email systems.

    Vivat diversitas.



  • Is it? Really? Easier for non-technical users than Markdown?

    Most simple markup languages (djot, markdown, asciidoc, textile, etc.) are based on 7-bit ASCII markup that people have been using in email and SMS for decades. They’re compact and straightforward. BBCode is a bastardization (I use that in its technical sense more than as a pejorative) of HTML; it’s verbose and unintuitive.

    Give a non-technical person with no other information a keyboard and a plain text field and ask them to emphasize a word in some text. I’ll bet the first thing they do is all caps. If you ask them to do it without caps, I bet you’ll get something like surrounding the text in asterisks or hashmarks, but regardless, what you won’t get is bracket-B-bracket followed by a closing tag.

    BBCode is just straight-up HTML for people allergic to pointy characters. That’s hardly non-technical.