Oddbean

samsies but for relays, brain hurtz Write ACLS was hard enough, and now we have NIP-42 AUTH read ACLs to layer on top of write. 'Types' of relays expanding constantly. People using Relays as TCP/IP, using them as base64 image servers, using them as DNS, using them as cashu wallets, using them for anything and not really saying what they're using them for. Unlimited "kinds", or limited, but who knows what they even are? Github searching the nips repo like a donkey with rabies and not finding anything you need to find, forced to login and KYC with them just to search. Kinds galore, kinds upon kinds.. What to limit what to not limit? Will people even use lightning or will clients even help them pay for relays or just keep giving it away for free? Servers exploding under 60+ load average and then having zero traffic. Clients sending drafts to 600+ relays on every keystroke via blastr. Like bots, follow bots, happy new year bots, comment bots, stalker bots, denial of service bots, jealous bots, bots that are ok. Implementing 'private inboxes' to allow everyone to connect and AUTH, but only allow them to send a message if they're a subscriber, but ALSO allow anyone to send if they tag someone who IS a subscriber, but only if it's a 'private message' of 6-7 different kinds. Only allowing each individual pubkey to download their OWN private messages if they're a subscriber instead of the whole network of private messages. Allowing things, blocking things, but override the allows with blocks, and then do that for reads AND writes, and for kinds and pubkeys and keywords, but with separate logic when required. Well, I am looking forward to client outboxes/inboxes and upgrading all relays to AUTH so much and I know it's super hard. The relays will be here to support you. If anyone can do it it's @Vitor Pamplona and @Magister Michael Dilger M.Sc. nostr:nevent1qqsr7tqzrv5ue7tra9traxkqct467r5ea0ph2v9z4mdag3myelcugxcudvj2c

been saying this for about 3 months, there needs to be a field in the filter to exclude event IDs from being sent back.. or a bloom filter for excludes, whichever thing you think is more expensive, bloom filter match or the space for the exclude event ID array anyhow, y'all gonna figure it out one way or another, i've worked out that none of you pay that much attention to what i say, and i get to play Cassandra in this show

In principle I can see the merit. But in practice I see problems. Sending huge numbers of IDs to exclude is itself expensive. Bloom filters aren't precise. Negentropy (the other solution often suggested) requires potentially a lot of round trips. There are possibly other solutions like getting all the IDs first and then asking for only some of those events. Also 256-bit IDs are cryptographically unique but we don't need cryptographic uniqueness for this avoid-double-event problem, just practical uniqueness, so using the first 64 bits of an ID to make it shorter is a reasonable optimization to whichever solution arises as the best. I haven't heard anybody make an argument that compares the options and concludes as to which option is superior, so we are still in an exploratory stage as to this issue. But I don't deny the problem.

i think we are also in a phase where we are growing out of the idea of "dumb relay" and into the "modular relay that has multiple services" phase there really is nothing stopping someone making a neat GraphQL query API interface to a relay database, it's really just a question of writing queries and creating indexes

I am driven towards solving these kinds of core complexity issues you mention. Gossip client rarely gets new features because I spend most of my time fixing or improving core logic in the face of nostr complexity. As time goes on, the fundamental problems that I attack next tend to be more and more complex, and progress tends to appear slower and slower. I'm mostly entirely ignoring all the new kinds and new ways to use relays. We all have different roles to play and it is information overload everytime I open my github notifications.