It depends what you see a social protocol as. Before nostr we had signed json events on websocket relays. Then we had nostr. And now we are more or less back to signed json events on websocket relays. For me a social protocol is a set of guarantees. Not perfect guarantees, mind you, but still, strong ones. A guarantee that if you add a relay it'll work, just as any other relay. That if you write a note it'll get shown just the way you wrote it. The vision for nostr, as I understand it, was a very limited number of quite strong guarantees. But now we're back to a space with so few guarantees that we can more or less say we have no guarantees. When people talk about nostr now, they're often actually talking about signed json events on websocket relays, the thing we had before nostr. Relays are not guaranteed to work, for whatever thing you're trying to do. DMs are not guarantees to be sent to who you send them to. Media are not guaranteed to load. Sing-in methods are not guaranteed to be supported. The list of guarantee-less and guarantee eroded things goes on. Does this mean signed json events on websocket relays are bad? No, they work great as an alternative to APIs, and much of the tooling for this that's come out here is great. But it's gone from being a social protocol that your average social human being can wrap their head around to being a sort of devkit for json events on websocket relays, and my take is that this is a bummer. Making a client for more constrained things doesn't work. Any client would suffer from the current lack of guarantees. We're at the point where if a dev wants those guarantees back then at the very least a soft fork is needed.