Replying to Avatar HoloKat

Kat’s 2 sats:

I’m well aware of the nostr principles and various considerations a developer might make before integrating something that has potential to get rugged.

I’m also considerate of user desires and how they might fit into the overall product vision.

There are always trade offs with any decision. Do we make users happy? Or do we adhere to principles of rug-proofing?

I think it helps to look at the bigger picture and try to imagine what is more likely to happen - your brand new protocol dying because users were unhappy with the overall experience, or potentially having a part of your client not work if the centralized API is rugged.

Personally, I see former as a greater threat when considering that the features that might be rugged are not really core to the overall app experience. I’d much rather make users happy (and even charge them for it), then worry about media disappearing. Our words are the ultimate speech. We can continue communicating with words, even if media is gone.

For this reason, I see un-ruggable media is a nice to have, but not critical to success. If media dies, you still have time to replace it with another solution, but if the word dies, that’s it, most of your users will disappear (except the super hardcore ones who will wait for it to come back up).

The cool thing about nostr is that we have all these different clients who can do as they please and choose the path that works best for them and their own principles. We can’t really force anyone to do anything. Shouting at devs is defiantly not the way to get anything done. Ok to keep bringing it up, and even better if an issue is encouraged with some sats. I know that works because I have done it myself several times now. Those sats are not much, doesn’t really cover any real expense for developer, but it’s proof of work and very good signal.

As for “build it better yourself”, this is not a viable path. We already have very limited number of developers here, truth is that we can’t build it better ourselves. We all have different roles to play, all critical to success, but different. I would encourage developers to pay attention to user feedback, especially if it’s the same feedback over and over from multiple passionate and hardcore users - they are your signal and a good indicator if something is going right or wrong.

Anyway, love you all! 💜 Let there be peace!

The issue is less of unruggable media, the issue is more of a ruggable api once you hit api limits, maybe that was lost in translation

Reply to this note

Please Login to reply.

Discussion

Meaning you’d need to pay and there’s uncertainty if users would pay for it?

It means they can break your app at any moment for any reason. I would rather build a solution that doesn’t break

What does “break the app” entail? We’d still see notes, just not the media? Or would it be something more serious?

The gif feature would stop working

This is a fair concern for you to have, but all you would have to do is make a note about how a centralized service broke the feature and we'd all zap and feel your pain, not blaming you for it at all.

💥

People always tell me they come back to damus because it’s reliable. There’s a reason it’s reliable, it’s exactly because I don’t have many centralized integrations. The only main one is nostr.build, and it’s the most complained about thing when it goes down or when users hit the upload limit.

If i didn’t have these principles then damus wouldn’t be damus. People can say i’m not listening to users (which is not true), i am just not going to make damus more brittle over time. My goal is that it will keep working even after I’m dead, even with noone around to maintain it.

I respect the principles 🫂

Reliability is definitely one of the primary reasons I use Damus too. That and I like the design.

The brightest stars burn fastest. Its not always about moving fast and breaking things, especially if you want to stick around for a while.

Decentralization isn’t just about censorship resistance, its about building better solutions that don’t rely on the existing ways of doing things. Ways that are more private and don’t have downtime or reliance on apis that disappear and go down

How do we have a more local gif library that clients can tap into? It seems plebhy gifs are just stored on their server