git server sounds centralized, ipfs can be decentralize, just for backup .
From a698fef13317b7cba8dee9884b8d564ed8bf9ee7 Mon Sep 17 00:00:00 2001
Subject: [PATCH 0/6] fix linting, tests and a bug
the purpose of this proposal is to combine the fiatjaf and DanConwayDev branches which got out of sync. it proposes changes to be applied on top of the tip in https://github.com/fiatjaf/nostr-profile-manager. we should also agree which remote git repository should be used as the authoritative. I'm happy to mark my github repository as stale and use yours. what is the state of song? perhaps we could move it completely off github and use that instead? nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uqzq6mj5wedl3wm9hg5u6cd6jqunquy39qdnv7e3hycs8qss6skn2ggcxz6g8
Discussion
The intention is to enable multiple git servers which all act as mirrors behind an authorative state issued through nostr events. IPFS could act as a got server in this scenario if the git-remote-helper works. That project looks a little stale.
as it is , but we discuss concepts here, right ?
Yes. Do you see IPFS being used for anything other than the functionality delivered in a standard git server?
Fixing that git helper should be easy, however before you invest too much in IPFS, beware its DHT is poorly designed and IPFS as whole scale well.
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.
Ok the "collaboration side" is like issues and PRs?
Yes, including a contributor sharing their code.
Ok. Yeah fine go ahead figure it out. I need the complete solution though so back to the drawing board for me.
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
If there's an authoritative state it has to be centralized somehow.
If there isn't an authoritative state then there has to be a consensus mechanism and I don't see one.
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.
Sorry, "multiple" and "authoritative" are contradictions in terms.
I know Linux has multiple branches but each branch only has one state.
If both you and I push commits to branch "foo" which one is the correct "foo".
I don't think you've thought this through.
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.
Maybe ... I think this needs to be figured out and baked into the system. Don't leave solving the hard part to the user if that's what you head in mind.
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?
Better earlier than later. Duh.
> If someone tries to game this, the intention is to add web of trust into this.
I believe that when I see that.
Your sceptical that web of trust will be added? Why's that?
"Web of trust" is some sort of buzzword only. It can mean anything and everything.
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.
Yeah any such numbers metric will easily be gamed.
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.
> 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.
Whatever consensus protocol you come up with must also work decentralized. Gitworkshop.dev is centralized.
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.
There is also a larger problem here. Your thinking revolves around isolated, single responsitories. But the open source world has repositories referring to one another.
Example: https://github.com/simplex-chat/simplex-chat/blob/stable/cabal.project #L34
The whole chain of repositories must be decentralized and highly available. This is the problem I have to solve.
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?
Relying on the centralized package manager's idea of what the authoritative state is is a serious bottleneck.
This is why lock files are being used for each project to define its own state.
This is @simplex lock file: https://github.com/simplex-chat/simplex-chat/blob/stable/flake.lock
Each time it says "github" that's a centralized bottleneck that must go away.
isn't it appropriate for a project to use a lock file to specify a specific state of a dependnancy so errors due to a dependency update can be diagnosed?
Yes uh I'm confused didn't we discuss this in the quoted thread? What's your question? The problem is how to find git or package repos of dependencies.
You can't just have a radicle ID (rid), you also need to know a bootstrap node of the respective swarm the repo is in. The bootstrap node then becomes a single point of failure the way GitHub is a single point of failure now.
cc nostr:npub1axy65mspxl2j5sgweky6uk0h4klmp00vj7rtjxquxure2j6vlf5smh6ukq
There are (at least) two quite different problems here:
1) how do I decide which version of a dependency version I should use? Many projects trust package management tools (yarn, cargo, etc) and centralised repositories (crates.io, etc) to serve them the most suitable hashed state via commands like `yarn update` and `cargo update`. To what extent are these states signed by the dependency's maintainers and to what extent are these signatures validated on the developers machine across language and package management ecosystems? I'd be interested to see some analysis of this.
2) how can I download a specific version of a dependencies without relying on a centralised entity (github)
(1) is a good question. Form the time being I'm assuming we have already determined a hash. So I'm trying to solve (2).
Mind you (2) happens much more often and in an automated fashion, (1) can be manual for the time being.
Bittorrent and Magnet Links?
Dreamt-up end state:
All deps are seeded right from build servers where the code is still pristine (or even from production servers, e.g. for Ruby gems if maintainers started including the tests and docs again, which they don‘t seem to be willing to do, see https://github.com/orgs/rubygems/discussions/7551#discussioncomment-8981632 )
Btw this is how this thread appears in my client.
I'd this primal? I dont like how some clients punish nested replies and others display unnested replies out of conversation order.
It's Plebstr. Yes I will upgrade to the new Openvibe soon. I think it's not related to nesting, it can't find the missing note on any relay? I have like 20 or so including all the ones Amethyst comes with.