Avatar
fiatjaf
3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d
~

I was kidding. In my mind the shares would just be entries on a database. This relay cannot be anything other than a centralized entity, as it is running a server on a domain name anyway.

Is subscribing to relays -- as entities themselves, not only as vehicles -- the future of the "global feed"?

Now what if we release the shares as assets on a blockchain?

Someone should do a relay that is very-high signal. It can issue shares of revenue of that relay and then charge for each note submitted to it.

Shareholders take a cut of the revenue, but are bound to vote on whether a note is worth being published or not. If they vote no when most people voted yes or vice-versa they lose a small fraction of their shares, the shares go to those who voted with the majority.

Would this work? Why not?

I have a systemd scheduled service.

The point of Nostr is that different people will make different choices for how to filter things and where to connect to. You want to impose your view on everybody. Instead, you should be supporting initiatives that give the user more control while still keeping everything interoperable and open. That will create an environment in which your desired solution has more chance of being fulfilled.

Can you try multiple times with small values and tell me if the error persists? Also, are you in one of the US sanctioned countries?

Over my dead body.

We've focused too much on cool math and code and not enough on actual real-world use cases.

To support edits on normal text notes would put an insurmountable burden on all clients and the complexity would be so huge that no one would be able to write a client ever again.

What do you think of https://github.com/nostr-protocol/nips/issues/236?

Maybe it is time for a backwards-compatible general cleanup on the Nostr spec? But it will only work if developers are onboard.

I'm not sure what to think myself.