Avatar
fiatjaf
3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d
~

they are very wasteful indeed, we should instead have a very efficient binary format that only 3 people would be able to implement after 26 days of coding and 32 unit tests

what NIP is that? I am lost

the only problem I have with alphaama is that whenever I want to reply to any thread it gets bumped to the top and I am also bumped to the top so I can't just continue scrolling down from where I was.

I think they are very good -- not perfect, sometimes confusing, but better than anything else I've ever seen.

yes, it is dead, do not bother

why is it antithetical to whatever?

expensive relays are not a pipe dream, because spam must be solved. I grant that most people will not want to pay (although the number of people willing to pay will get lower if the friction and price gets lower too), but for those who are willing to, expensive relays are a great solution to proving themselves to not be spambots.

other solutions are possible at the same time, involving manual approval of users or proof-of-work or soft-KYC or relays that pay high prices for machine-learning to filter spam but then they sell your data to pay for these losses and who knows what else.

what do you mean by "p2p will work itself into the network reducing relays"? p2p doesn't work today, so it probably won't work when the network has many thousands of users.

unless you mean p2p between relays or just everybody publishing all events to all relays -- that also won't work because relays are not expected to handle _all events in the world_, and that is what makes nostr scalable.

content has value so... value should have content?

imagine you pay to host an event on some relay, then someone else also republishes that same event there, and then another one. the relay keeps pocketing the money and only has to store one event :P

with nostr if we reduce these 5 error conditions to just 2 that will be good enough.

I very much dislike HTTP response status codes. HTTP is very annoying because a request can fail in so many different ways: connection error, status code wrong, response may be invalid JSON, response may be valid JSON with an `"error"` property somewhere.

sounds good to me.

I think nostr-tools actually sets up a new subscription on that event id when publishing, then gets it back and closes the subscription.

it will still work in most cases I imagine.

also maybe even private or niche or paid relays etc may want to accept event that are referenced by other events, i.e. if my relay only takes events from bob, but bob has sent an event with an 'e' tag to 'xyz' then I may also accept 'xyz' if it is sent right after?

you won the day with that idea