ok, so sounds like you consider that you've discussed this with enough experts to not benefit from opening the designs

ok, sure, let me ask you this, then:

do you not feel like opening the architecture/design might help inspire building some other stuff?

I honestly don't understand what's the reticence to opening it up, is it that you want to prevent others from copying it or something like that?

Satoshi posted super shitty code too; he didn’t wait to make it all nice, and pretty and functional

I don’t understand the approach of building it in stealth mode, honestly;

don’t you think your approach/designs/implementations might benefit from people who are not exclusively in your team?

🪺

Can you link the repo? Would love to see the building process and everything you and your team have already come up with.

There would still be many apps no matter how good the universal specifications are. As you said previously, the Nostr protocol is not only for social media, far from it. And even within the social media use case, the apps are noticeably more efficient when coded natively for one specific platform. For example Flutter vs. Kotlin or Swift.

Yeah my point was there's not as much incentive to mend the already breaking interoperability in Nostr than there is in Bitcoin. Although there will be enormous pressure to make apps on Nostr fully interoperable, it's not as clear who is in the right because there is no consensus mechanism like there is in Bitcoin. The longest chain wins. The fork with the highest hashrate wins. Which client implementation wins on Nostr? Who knows? What do you mean by universal consensus btw?

True, you have a point there. If a rogue dev breaks interoperability badly enough, no one will want to use the app anymore, forcing the dev(s) to either ensure interoperability or lose contributors and users. Nothing a single dev can do about it. That's the beauty of Nostr.

Those developer factions will not include their users. Users of the clients will always want to see messages from each other, no matter what client they are using. Users are not going to be ideologically split by the ideology of the authors of their favorite client.

This means that the client developers will find themselves under very intense pressure to cooperate and interoperate. They can stamp their feet all they want; and throw all the tantrums they like. But they WILL eventually be forced, by their constinuents, to work together.

They can do this the easy way, or the hard way, but they will eventually do it.

Because WE are nostr, not THEY.

>From: (cypherhoodlum) at 04/25/23 08:04:32 on wss://relay.damus.io

>---------------

>Bitcoin and Nostr are different though, because Nostr doesn't have any consensus algorithm. If you stubbornly choose the wrong chain, you lose money or degrade your security. If you choose "the wrong nostr client" (which doesn't exist) your client is not interoperable with other clients. Factions emerge and social networks split, but there is no economical incentive to switch clients whatsoever.

Bitcoin and Nostr are different though, because Nostr doesn't have any consensus algorithm. If you stubbornly choose the wrong chain, you lose money or degrade your security. If you choose "the wrong nostr client" (which doesn't exist) your client is not interoperable with other clients. Factions emerge and social networks split, but there is no economical incentive to switch clients whatsoever.

It works for #bitcoin, and it will work here if the new standard is excellent.

Wait and see… Universal consensus is a deep beauty of decentralized protocols, because social consensus doesn’t scale — as you can probably tell by the bickering between different client-devs.

"We have too many standards! Let's make one more standard to solve the too many standards problem!"

At this point, that probably won't work as intended.

In life, there are times when you don't have friends around you.

But if you look around the world, there are many friends.

I think so.

#Plebchain

I agree

I don't think a github replacement should be a bounty itself: it's too large a project imo

are you planning on keeping the repo itself on relays???

Awesome! Thoughts on this protocol for file transfers? nostr:note1es4674ajsdp3n5w8asyhdt3d7qkcdw4rpalkhkuglj74nljh8pvsn0nlhm seems like a new approach at the very least

back in january I started working on a github replacement.... until I saw the bounty get posted;

I thought it would immediately get filled so I moved on to other stuff

can't believe it's April and it's still not ready

On the other hand, if backwards compatibility does ever need to be broken for something, it’s better to do it now than later

#[2]​ can we come back to a common standard here?