pull down to refresh
110 sats \ 0 replies \ @gregory 27 Sep 2023 \ on: What makes you optimistic about the world? meta
https://news.mit.edu/2023/desalination-system-could-produce-freshwater-cheaper-0927
That is kinda how Nostr is meant to work. But there’s an open debate in the dev community about how much to put in relays (just text? Images? Videos?) it’s still an outstanding question.
If relays house too much data it’ll be hard for people to run small relays so the network will be more centralised. If relays don’t allow people to store whole files in them, then those files will have to be stored somewhere.
Personally I’d like to keep big files off relays and lets solutions like Nostr.build provide specialised efficient offerings and accept Bitcoin as payment.
But there’s already apps that allow a Nostr user to create notes and store them on relays.
I wish we’d stop talking about the price.
The good news isn’t the price.
The good news is that Bitcoin is going to be more available 💪
I wrote almost the same thing here https://gregwhite.blog/decentralization/
Decentralization matters in places where power accumulate and is abused. Not everywhere.
I'm a bit of a drivechain noob, but this seems kinda like Liquid Network in that it's federated trust.
It's just via Sentinels as opposed to Liquid's set of ~15 trusted entities.
Is the idea that this strikes a balance between: On the one hand have miners being the authority that can allow illegal peg outs with a 51% attack (like most side chain proposals I've seen), and on the other hand having 15 assigned authorities (like Liquid)?
I think it could be better than other proposals, but I wanna make sure I understand.
Agreed, I think the email model is powerful for nostr but the aggressiveness will be tuned to match the desiers of people on Nostr because of exactly what you're saying.
There's another paradigm for spam control on a decentralized protocol that's been operating for decades: email.
It has its flaws but there are groups that collect spam reports and publish a list of how spammy they think an email address / email sending IP is. And email inboxes subscribe to whatever lists they want to trust (and maybe publish their own!)
I could see that working for Nostr too. Some groups will monitor relays for "report" kind events and make judgemetn calls based on their algorithm of which pubkeys are spammy (or even just tag them as NSFW poster, or "posts only cute dog videos" or any other label that clients and users may want to utilize to filter their feeds.
I think that proof of work and making posts cost money can help a lot! But at the end of the day some spam will be worth the cost if it is able to be effective at scamming.
It may be more work to go with a model like this, but I think it'll preserve censorship resistance of nostr (because you can choose relays that listen to lists you agree with, or none at all); while also giving some measure of filtering power that isn't on every user to make a robust mute list.
- Fair! But I think that it'll raise a HTTP 400 error which is exactly the error to send to the frontend to handle. It even tells the frontend which field needs to be fixed and the specific error on that field. Django does some great work here.
- Agreed it could use some more robust error handling, but the several places that call
update_metadata
do have try except blocks around them to process any errors and re-raise if appropriate. - Totally, I am using env variables the defaults there are just the values that are used in development (they match how the db is set up via docker-compose). The only one I see that's set that could be an issue is the Django Secret Key, which is only important for encrypted fields which I don't think there are any in this data model.
I'll definitely be making improvements but thanks for taking the time to look through it!
I think that it can go either way, but for now I think a main site where people can add features to it if they like. I'm planning to do a majority of the work until people find it useful enough they want it improved faster than I can do it.
I agree with you, relays are something we need more focus on as we scale. Can't wait to be of use!