Avatar
Matt ๐Ÿš€
26eb0b67b66fa45e4885580f65c602139e56e43d7b79718abdf32395b3a94722
Software engineer ๐Ÿ’ป geeking out on Bitcoin, if Iโ€™m not watching something about space and the universe ๐Ÿ”ญ then youโ€™ll probably find me fishing ๐ŸŽฃ or gaming ๐ŸŽฎ

Had to block a few of those already, and the cowdle word game, cool concept but when my stream fills up with one word notes because a follower is constantly playing it then it had to go straight into the block bin

You certainly can, Iโ€™ve already done that (wrote a git-remote-helper which would create (or pull) events) these events where as you says the individual objects and refs of a repository, it works but itโ€™s a very bad idea for many reasons. So although we can, we definitely do not want to store a repo with events.

Hereโ€™s a couple screenshots of a prototype I built around this a couple weeks ago. Getting repos pushing/pulling over nostr and storing the contents of the repo is not the problem, that was easy, the problems come when some events exist on relay and not another depending on collaborators relays when pushing, this could be solved by storing the relay to publish to along with the repository metadata but I wouldnโ€™t want to rely on a relay storing each git object. Nostr for social side is the way to go, git server sending updates to nostr relays as and when things happen but not the git objects themselves. That was the output from my exploration.

Note in the screenshot before pushing anything to a repo the remote protocol (nostr://)

Tags are just refs like any branch, so I donโ€™t think either of these belong on a nostr relay at all. All got objects (commits, trees, blobs) and refs (heads/tags) should be stored like any got repository on a filesystem, that way all clients would be looking at the same remote repository data and all devs would be working on the same code base regardless of relays each contributor uses. Nostr events would describe things that donโ€™t live on a hit repository such as pull requests, issues, comments etc. A repository event may exist in nostr but it should probably serve to only provide metadata about a remote repository (name, description, remote/git-server)

Agreed, the approach I played around with was interesting and fun getting it working but it certainly seems to be a bad approach, single source of truth as you mentioned being one. Having a nostr github replacement would definitely still want to store repositories in a traditional git repository rather than nostr events ๐Ÿ™‚

๐Ÿ˜‚ This is pure comedy, had phantom scribbler chose to post this on nostr the zaps would be flying โšก๏ธ

#[0]

๐Ÿซก followed #plebchain

Iโ€™ve just had my first random #zap encounter, thank you to whoever sent me those 21 sats youโ€™re awesome ๐Ÿคฉ

And on that note, Iโ€™ve also hit a milestone, 69 followers, feeling accomplished ๐Ÿ˜€

#plebchain

Do you host your node at home or cloud provider? The cost of electricity here is at an all time high, which is a concern for leaving a machine running 24/7 at home, I run bitcoin core at home but itโ€™s not online all the time, I understand thatโ€™s a bit different as lightning nodes gain โ€œreputationโ€ with reliability/uptime being a factor so if I was to run a lightning node it would make more sense financially to pay a small monthly fee to host it elsewhere rather than a huge electricity bill.

How would you see a GitHub replacement work with nostr? I did quite a bit of experimentation a couple of weeks ago, I was able to push/pull repositories with all got objects and refs being stored as events, it was surprisingly quick but it felt like the wrong direction. Do you see bitcoin core having their own git server with a nostr frontend and the social/collaboration side of GitHub (issues/pull-requests/comments etc) would be powered by nostr or something entirely different? https://github.com/nostr-protocol/nips/pull/223#issuecomment-1419642826

Zapped 8888, enjoy the wine ๐Ÿท

Invoice expired, setup lnurl on your profile Iโ€™ll zap you the admin fee โšก๏ธ