Oddbean

I see. I checked strfry issues, I don't see your bounty, maybe it should be there? Btw we've just added bounties to github issues on nostrapp.link, check the issues tab here https://nostrapp.link/r/naddr1qqvkw6t5dp6kytnrdakj76r0096x2cmg9aehgunxwfusyg9r89n595twyzwmaak70pgzfqvw076m0a5dnfkraeljrfmjtgfl25psgqqqwkjs2dxul7 - I've posted 300k bounty to the nip42 issue now. khatru looks cool, especially for custom relays that aren't expected to handle high loads.

Khatru does look really cool, and I like that it's written in golang. I haven't benchmarked it or anything but it does support lmdb so it might be quite fast. I don't believe in bounties.. I think it hurts collaboration on opensource projects as it tends to create a competiton.. So I tried something different, I 'notarized' a reward and tried to find developers who were capable and would want to work on it... it didn't really go anywhere though, and now that you reminded me maybe I should post it on ostrich.work or put the word out again. It might just be a really difficult thing to add to strfry as well as scope was tending to creep out of control. The other options may make more sense.

I'm not sure bounties and competition are bad. Right now there is total lack of competition for solving issues, so some incentives to ignite it would be useful IMO. A simple implementation of nip42 with some fixed set of pre-configured pubkeys doesn't seem too difficult from what I see in the code. The scope of "full support" (relay+sync+stream) mentioned in the github issue plus the desire to make it an extensible plugin might be the thing blocking it.

My problem with bounties is say for example it's a project where multiple people want to do it (like the git on nostr thing). The amount of work that would take and the high bounty means someone would get burned real bad if they worked on it and didn't get it. So they have incentive to work on it without collaborating. And it also probably requires NIPs, which are hard enough to get a consensus, even without a competition in the background muddling the situation. So that's why we don't have git on nostr yet imho. For strfry tho, there are so few that could do it you're probably right that a bounty wouldn't be bad for this one.. 🤔

100% agree that the bigger the problem scope, the harder it is, but then a big problem scope is itself a problem. I think bounties for github issues are a much better way to do these incentives, as the scope is usually much smaller. And if the issue is of a big scope then you can just create another smaller-scope issue and attach bounty to that one.

It was a little disappointing, the person that was trying to do this already, had hired someone to do it.. but they couldn't do it. From what I could tell, they got hung up on the implementation details and it got more and more complicated .. similar to what mazin was saying.. there is a branch somewhere with where they left off.

For your use case, you mentioned a 'client' auth.. do you mean auth per person or auth for an entire client application somehow? Just was wondering. I agree that keeping it very simple would be best. Even the stuff that 'makes DMs more private', I don't think is necessary.

I mean that if I want to create a relay for some 'curated' set of events then I would just allow only one pubkey to do writes (write anything, not just it's events), and let everyone else read. Curation could happen manually - I could use some tool to broadcast specific events to that relay, or by some software with keys that are allowed to write. I think even this seemingly simple 'auth only for writes' case isn't trivial - if you send AUTH to every new connection then you're forcing readers to auth. And if you only send AUTH on writes (EVENT commands) then there needs to be a mechanism to handle the pending write - relay would either have to reject the first write attempt, do AUTH and then client should retry, or relay should buffer the write request, do AUTH and commit the write if auth succeeds. And since clients can't launch the auth flow, writers can't initiate it themselves, they have to wait until relay decided to run the auth flow. NIP-42 isn't great.

Maybe that's not a great solution btw. If a dedicated writer is mistaken and decides to delete some event from strfry - what should it do?... Maybe a better solution is some relay management interface/port/etc. It could require auth for all clients and support more commands (at least delete). Do you know if there is anything like that planned/built for strfry?

Well, right now the relays do accept delete commands from any moderator. Right now it's using 1984 but it could listen for any event from a mod and perform a delete action.. Using this same technique, it might be possible use a new event kind from a moderator, and unwrap an event that you were to send it and inject it straight into the relay bypassing the ACLs..

That's fun, but it sounds like such logic should be handled by separate writer/automation process with custom logic. How about a bearer auth token in headers that allows writes? This would exclude most of existing software to rebroadcast notes to that relay, but it should be trivial to implement at strfry and then we could build various "plugins" that would handle the above or other interesting curation logics.

Ya it's funny I was just searching around for doing header auth on websocket upgrades and it sounds like browsers (JavaScript websocket API) don't support this.. course that's just stackoverflow I didn't deep dive on it. 😁

Oh shit that's true, no websocket headers from browsers :( It could be a 'secret' included in url but then it will be logged by every damn thing in the middle of you and the relay, not sure if passing long-lived secrets in urls is a good practice.

One other crazy idea, is that you could have two relays. One with an obfuscated url, and one for the public. Then use streaming behind the scenes to move the events across.. anyone with the obfuscated url would have write.

Also not sure if using secret url is a good idea nostr:nevent1qqsrcndt8wmv7erlccjf6kcamsr2pzferkxa70fcc0fk3q2gny7wnmqpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59upzqv6kmesm89j8jvww3vs5pv46hqm7pqgvpm63twlf9hszfqzqhz7aqvzqqqqqqymcd79w