I'm glad someone else is working on the problem. I'd love to take a look at your work. There is a catch 22.
As I understand it, you have put the tool to clone repositories from kind 0 events, in your kind 0 event. I can't clone the repo without the tool, which is only available in the repo.
Is your intention to build something that other people would use or for personal use?
At the moment I think the direction nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s and seem to approve of is using the patch model. Everything else appears not to be fleshed out.
I think the patch model doesn't scale but is a good starting point because of it's simplicity.
I am not used to working in public either. There hasn't been any engagement with my long form posts on the issue. No one has commented on my draft NIP. My plan is to build a prototype and put it out there.
Also, is there a way to get some feedback from someone who would know, say,
how big I can make a kind-0 before relays start rejecting it?
I tried tagging 4 devs but not one seems to care... I tried asking someone
who runs a relay before and got no answer.
nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr
I have found its really hard to get feedback. Its probably a reputation thing. The small number of core devs are probably tagged in more messages than they have time to read given the growth of nostr.
Working on a bounty or two might be a good way to build relationships?
Nostr is permissionless. Perhaps just broadcast a bunch of different sized messages to lots of relays under a fresh pubkey and see which ones get rejected?
only a subset of events would be needed to rebuild the state.
Check out this draft NIP for authorisation groups on nostr: https://github.com/nostr-protocol/nips/pull/483
Yes, I working on it. Check out my long form nostr posts. I'll post a prototype CLI in Rust soon. Happy to discuss on a call if you like?
Important people of nostr, where you at...
I put a git repo on nostr and I'd like some feedback.
Git repo stored in a kind-0 field, pull requests, issues, etc as regular notes. Thoughts?
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s
nostr:npub108kuptq55xrxqc8ttfjqwwhkh7ruur7d3drm2yyp8ul9t86w9g0s3v9usw
nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c
If a repo was its own event with updates posted in reply, a repo would have animmutable ID. This is similar to what I propose in https://github.com/nostr-protocol/nips/pull/483/commits
Important people of nostr, where you at...
I put a git repo on nostr and I'd like some feedback.
Git repo stored in a kind-0 field, pull requests, issues, etc as regular notes. Thoughts?
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s
nostr:npub108kuptq55xrxqc8ttfjqwwhkh7ruur7d3drm2yyp8ul9t86w9g0s3v9usw
nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c
What about state management of repos, PRs and issues? The author / maintainers should be able to mark them as closed / merged.
Good point about the free compute power. I missed that in my analysis
naddr1qqyxxdmyvsmrqdn9qywhwumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wspzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqvzqqqr4guzzjrgj
the standard commands must be supported. Clone, pull and push could all be abstracted through a wrapper that receives and sends only patches over Nostr.
What about verifying an authorised state when the list of maintainers evolves overtime?
I should probably expand on this in a long form note so that my three other long form buddies can agree with me.
I feel the exact opposite. You can build an argument in long form. Short form is for sound bites.
I agree that a large bounty doesn't put the right incentives in place. I'd love to work full time on this problem. Would you consider sponsoring a lead developer? I outline the key challenges as I see them here:
And the bull case for this here:
Not sure the best way to link to long form content that will display well across clients. https://blogstack.io/naddr1qqyxxwf4vccnwcmrqywhwumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wspzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqvzqqqr4guw0gazh
I'm not sure a grey or purple checks for a NIP-05 address is the best approach. The association with twitter's blue check gives the wrong impression of what sort of verification is happening. #[3]
#[4], Do you think its time to say goodbye to the blue/purple check for NIP-05 addresses? I make the case for it here: https://blogstack.io/naddr1qqyxxwf4vccnwcmrqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsyg9qpr00z4uklw56p4h6kp8gl4ts3y59m874qhd94ql732k40g6kf5psgqqqw4rshy3kcn
I love the focus on empowering users. By 'turn off replies' do you mean 1) allow damus users to prevent seeing replies to their own notes 2) send metadata in the note that expresses their wish for no replies / only replies from a subset of users that clients can choose to respect or not 3) remove the option from damus to reply to these messages / view replies to original author does not?
I have published a NIP-23 on The Bull Case for a GitHub Alternative on Nostr https://blogstack.io/naddr1qqyr2wt9xfsk2wp3qy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsyg9qpr00z4uklw56p4h6kp8gl4ts3y59m874qhd94ql732k40g6kf5psgqqqw4rsd8v7ng