Repeatedly nuked profile

An interesting aspect of decentralised protocol design is how to avoid day-one community capture, meaning one relatively well-defined (but admittedly polarising or off-putting) community sets up shop early on, and in doing so kills off future growth. Much of the focus to date has been on how to design the tech so as not to be exclusionary. But if the day-one community is exclusionary, then it doesn’t matter so much that the tech is not. You’re just trading one exclusionary vector (central ownership) for another (community capture). The is a very hard challenge.

Hot take: inflation doesn't really mean anything. 50 years ago, if you wanted the following: -1 flight Los Angelus to New York -1 basic television -100 large pizzas -100 litres of coke You'd have had to work twice as many hours as today. That's certainly not inflation in terms of hours worked. But you could easily make a list of things for which you'd have worked far fewer hours for 50 years ago. It depends what you value. If you just want to live in a van, watch TV, eat pizza drink coke and fly around the country then you haven't been affected by inflation at all, quite the opposite. But if you want a house in a trendy part of the city then you have been affected a lot. Inflation only means something in context of hours worked and personal priorities.

Anyone trying to encourage people who create good content to cross post to nostr under the notion that "it doesn't take much effort to cross post" is just utterly removed from the world of online authorship.

Nostr in a nutshell. 📝 e3189e81…

Nostr is what would happen if you asked a bunch of developers what non-developers might enjoy in a social network, and held back your giggles during the answer, and then said, maintaining a perfectly straight face, ”Yes, work with that”.

You cannot, in this day and age, launch a social app that has obvious missing features. So what triggers someone to conclude that a feature is obviously missing? One answer is using an established UX template that doesn’t have all the features seen as table stakes for that template. Another way to put this is that users have muscle memory. If you trigger this muscle memory with a templated UX, and then screw with it by not having these features, then these users are not going to like that. If you reuse a WhatsApp/Signal UX template then you need, for example, read receipts and emojis. These are table stakes for this template. If you don’t have these things then they will be seen by users as missing, indeed as gaping holes. One mistake developers often make is to assume that adding something ‘extra’ can make up for not having something expected. (“We don’t have read receipts but hey, we have zaps!”) In a muscle-memory scenario this never works. What can you add to a bicycle to make up for it not having brakes? Sure you can argue that there was a time when bicycles didn’t have breaks, but good luck with that argument. The key here is to NOT reuse a UX template that is going to trigger this muscle memory. Can’t deliver accurate follower counts? Then DO NOT reuse a Twitter UX template. Can’t deliver per-channel notification settings? Then DO NOT reuse a Discord UX template. Some caveats. First this mainly applies to the core features, the ones pretty much guaranteed to affect muscle memory. As you move to more tucked-away features then you could be okay, depending. And second this applies if you want to scale in a way that is meaningful in light of the number of human beings on planet earth. If you just want to tinker around with a few nerdy friends, do as you like. Of course certain features are hard in a decentralised context. The lesson is this. If you’ve got a UX template in mind, but it’s impossible to deliver a feature that is seen as table stakes for this template, and you’re hoping that something extra you have to add will make up for this gap—then stop. Ditch the template. Go for a totally different UX, something creative, new, not seen before, something that won’t trigger this muscle memory.