Can't read that without a twitter account lol twitter links are like road side litter now.

Good god the corporate web is falling apart. We get Reddit doing it's thing, now twitter requiring login to view tweets, completely negating the point of having a twitter account, what's next? Who else thinks Meta's "Threads" will die in a blaze of fire? I'm personally very excited to see it.

Or, you could realize that you can't outlegalese a ToS, look at the situation for what it is, see apple for what it is and never develop for their platform again.

So you gonna give up on Damus, or realize you've been giving your life to a multibillion dollar silo that runs entirely on conspicuous consumption prestige and vendor lock in and give up on Apple?

Dude no joke, I am basically ditching fedi and moving to this awesome protocol over all those shenanigans over there. All the screeching about Nazis and trans this and that have made that network practically unusable for anything but virtue signaling and shitposting. If youre a programmer or someone with some serious interest trying to discuss and share, good luck just doing that over there, it simply isn't possible.

Thanks, I'd heard of it but for some reason I thought it was proprietary.

Is there a FOSS lightning wallet for android that works with nostr (specifically onyx) and doesn't require me to run my own lightning node? I don't mind paying a little in fees for the luxury of not running a node.

Well, when I started following nostr development, there were something like 6 or 7 NIPs. I always thought that the organization of the message specification in NIP-01.

I always thought that it made sense to have 2 or 3 "kinds", that basically designated the target of the message, either "broadcast to followers" and "message for the relay" and with just those two distinctions you could organize the data in the message portion better without so many application specific NIPs. Then, the content could be more than just plaintext, it could be nested JSON depending on the application for the message. For example, it could be cyphertext with a type *in the content section* specific to the application that the client understands. The core nostr spec would remain fluid, unrestricted and available for any application, and the proposals wouldn't need to be implemented in the protocol and message, they would just be client/application specific implementations of nostr.

Instead, now, we have specific tags and types for things like profile changes, things that attempt to imitate existing tools as use cases of nostr directly in the protocol.

I'm not saying I hate it or anything, I understand your approach was to allow nostr to be what the userbase wanted it to be and not be too restrictive or ideological about the protocol design. do think though that design decisions early on ripple through time and affect the growth of the protocol and so a bit more thought and rigor in the design can go a long way. I think the path taken has sort of solidified it's design as a distributed twitter, and it could have been used to replace everything from email to lichess (to use a concrete example that has been implemented as a PoC) with an uncensorable protoclol capable of private message sending where needed.

Again, to reiterate, it's easy for me to armchair critique after you've done all the work and made this real. But I don't think it hurts for people to voice their perspective. If what I say sounds stupid feel free to teach me something I don't understand. If you like some of what I say that's good too, I like discussing protocol design and things like that, it's fun.

Personally I don't like all the application specific shit crammed in at this point. It would've been better to create a generic message structure that can be extended in an extra protocol way. But what do I know, everyone has an opinion and youre the one who made it. I'm sure it helps letting others make decisions and not being to critical, getting more contributors generates a userbase quickly.