Oddbean new post about | logout
▲ ▼
NabismoPrime | 1 months ago (raw) | root | parent | reply | flag 
 I think that's probably the more sensible solution. I am going to need to do a considerable about of refactoring to make that work on my end though. I could see benefits to both but think packaging it with the relay would be a much better UX.
▲ ▼
OceanSlim | 1 months ago (raw) | root | parent | reply | flag 
 If it's FOR the repo you're working on, I always think it should go in the repo. Making a different program for some other software you're working on add a dependency to them have to clone 2 bits of software to make 1 program work 100% of the way. Dependencies are fine, But if the software dependeds on a bit of code to be 100% functional, it should be in the same program. If that makes sense. Sounds kinda confusing ik... Like I'm making crawlr and blastr seperate from grain but the blastr is NEEDED for grain, it's just a specified 2nd relay for grain to send events to so it can be any relay. But the front end of grain should go with grain since it's part of the foundation. It doesn't HAVE to be but making it so means more congruency of the frontend to the back. If someone else wants to do a lot of work specific to the front, that's what branches are for.
▲ ▼
NabismoPrime | 1 months ago (raw) | root | parent | reply | flag 
 Definitely makes sense and this is something that would be necessary for my relay as I'm not looking to maintain both a GUI and CLI for the same purpose. My reasoning for possibly doing a local client was so that other people could use it using the methods from NIP-86 draft: https://github.com/nostr-protocol/nips/blob/relay-management-api/86.md . I guess I could keep a copy in a separate repo as a reference implementation if I really wanted to.