here is my honest answer:

1) It was my experience (a long time ago) that having a small relays list lead to people not getting my events and me not receiving other peoples events

2) I struggle to evaluate relays. many are really flaky (at least over VPN). the more I add the less I am trusting any one relay. I would love quality independent analysis of relays.

this is good. thanks for doing the analysis which lead to this.

I think I created https://metadata.nostr.com before the inbox / outbox terminology was in use. Its better language than read / write.

putting relays under 2 separate headings creates repetition

https://gitworkshop.dev and ngit used the gossip model from day 1 of the alpha release a few weeks ago. I think in some cases it can be easier for 'other stuff' clients to do this than social media type clients.

It's hard to penetrate the users contact list, or the contact list of contacts. But there might be a cat and mouse game with implementation detail so encoding it in a nip would probably not be worth it so clients use different approaches.

Yes. I do see that phrase banded about more than I see actual implentations of it.

I meant comparing numbers of repo event references in events authored by the users contacts or contacts contacts. Its quite plausible this could be 0 so a fallbck could be using a DVM to evaluate via contacts contacts contacts.

This is a good point. There is often a lock file referring to a particular state of each dependancy. However centralised package managers are almost always trusted by project maintainers to provide the authoritative latest state. There are usually only a small number of authoratitive package providers for each tech stack with have strategic lock due to network effect and language specific features.

Is this what you mean?

Only in as much as it is a web client so I could push changes to it without the knowlege and consent of users. Also there isn't a big diversity a nostr git clients so user choice is limited at the moment.

Your sceptical that web of trust will be added? Why's that?

I anticipate that the vast majority of repositories dont have their ownership contested by anyone but fraudsters so the current implemtnation is geared towards that.

Currently if there are multiple people who claim the same repository and they don't list the others as 'maintainers', gitworkshop.dev uses the one with the most references in other events. If they do, the event with the most recent created_at timestamp is used. If someone tries to game this, the intention is to add web of trust into this.

ngit also uses a maintainers.yaml file embedded into the commit history to indicate which npubs to treat as authoritative.

The tools are not yet geared towards multiple legitimate groups of maintainers with conflicting state.

I should probably write a more polished answer and publish it as a FAQ.

I'd love some more challenge around this as its better to find holes earlier rather than later when things are harder to change. What do you think?

Under the model I propose, nostr events communicate the authoritative state and git servers provide access to the code needed create this state. Alice and Bob both claim different states for the same repository and point to different git servers.

Which state does Carole see as authoritative? Maybe she knows and trusts Bob and chooses his. Maybe sees that other contributors she trusts have signed commits building on Alice's state and not Bobs so goes with Alice's.

There could be multiple authoratitive states. Like with the Linux kernel many entities maintain their own state and cherry pick commits from linus's branch.

Multiple git servers mirroring doesn't work for you? Maintainers would need to set them up but its a low lift for contributors? nostr:nevent1qqsgva2q9vp6e79p5tqsgye2gy4hdzgfwg89qhznxj2vcqne0fms8kqppemhxue69uhkummn9ekx7mp0qgs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngrqsqqqqqp3dsst8

The only way it would know about a missing note is if another note references it

What's wrong with using blaster for relay list replacable events per the gossip model? Why the need for on-chain data?

I'd this primal? I dont like how some clients punish nested replies and others display unnested replies out of conversation order.

Yes, including a contributor sharing their code.

No, I was just trying to understand whether you saw a role for it within the 'collaborarion' side of things. The link you sent me to the 'quiet' project was quite interesting and that is clearly in the collaboration space.

Right now my focus is on the collaboration side rather than the centralisation of the got server. Its the collaboration side where the biggest switching costs and opportunities are.

Yes. Do you see IPFS being used for anything other than the functionality delivered in a standard git server?