Nothing wrong with having a key pair, but yeah, most of the content in Nostr is unfortunately cryptocurrency related.
🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆.
𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍
Nothing wrong with having a key pair, but yeah, most of the content in Nostr is unfortunately cryptocurrency related.
Yeah, despite the strong anti-crypto sentiment on Lemmy, this is exactly the problem that projects like Nostr is trying to solve by integrating Lighting as a first-class payment system in the ecosystem.
Services get paid for by one of four ways:
Someone always pays; its expensive to host a popular instance. People suggesting you should host for free are selfish freeloaders, so know that some people understand that hosting costs, and sympathize with with your desire to offset that cost.
I like the volunteer micro-transaction model. Those who can afford to pay some amount for good service, and hopefully this provides welfare for those who can’t afford to pay. But the cryptocurrency space is a mess at the moment, and an economical currency (probably proof-of-stake rather than proof-of-work) needs to gain some traction, and overcome a lot of ignorant bigotry.
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.
Block the poster, or the whole magazine?
There are a lot of ways it could go wrong, for sure. IANAL, but lots of small and large companies have and do navigate these issues. But I wasn’t talking about legally contentious content; this would be a work-aruund for stuff that’s expensive to cache, or stuff you just don’t agree with and so don’t want to absorb the cost out of the goodness of yous heart. Just continue to defederate if you have any doubt.
Anyway, it was just a potential work-around to address OP’s issue. I’m not a Lemmy dev and won’t be implementing it.
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.
<sigh> Once more: Elon Musk is not God.
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.
Yeah, I get the origins. I wish there’d be a mime-type update to move it into modern times.
The irony is that they got it right in the 80’s. Simple markup conventions forced by pre-mime text/plain emails and, later in the 90’s, SMS are still the basis for most lightweight markup languages.
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.
Of all the markup languages in the world, why BBCode??
Agreed. By @FundMECFSResearch’s distinction, you (well, Americans) could choose to not pay taxes. You literally are able to not do it. Of course, you then have to deal with the consequences, but it falls in the same category of “optional.”
Gender-affirming surgery is “optional.” Eating food other than cat food is optional. Simply having the ability to make a choice between two options is not sufficient to justify saying both options are satisfactory.