In my proposal there are multiple packs relating to groups of commits in the history so the hashes don't change. Uding ^2 exponential.
Whilst smaller project often don't require advanced git features such as shallow clones and no-blob, they are essential for my larger open source projects. My goal is to make git nostr so attractive for open source projects that they all want to use it, no matter their size or complex.
nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk I considered using blossom, in fact I even wrote some code. nostr:nevent1qqsg9w72dve9myu29swk7w9wapqncndnhe98dmfrrd8cjd26fy3lsgsprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7q3q5qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exsxpqqqqr9zufx4r0 I thought the most efficent approach would be to store git packs as blossom blobs. I havent studied your code but from the documentation you are somehow using 2mb chunks? I can see how its naturaly evolved from your 'files' usecase.
Ultimately I prefer the trade-off of using a git server as its fundimantally compatible with all git usages (shallow sync, no-blob, etc) and git tooling. Grasp enable using the battle-tested, flexible and widely used git client-server model but frees it from a single server and moves the trust and authentication onto nostr. My guiding principle has been: let git be git and let nostr be nostr.
nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk I considered using blossom, in fact I even wrote some code. nostr:nevent1qqsg9w72dve9myu29swk7w9wapqncndnhe98dmfrrd8cjd26fy3lsgsprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7q3q5qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exsxpqqqqr9zufx4r0 I thought the most efficent approach would be to store git packs as blossom blobs. I havent studied your code but from the documentation you are somehow using 2mb chunks? I can see how its naturaly evolved from your 'files' usecase.
O. I thought that meant that it is online now but some sort of source fallback may not be yet. What exactly is online now?
This is because a git repository can't be found at the git.gitter.space address listed in the announcement. nostr:npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc?
Most of the time when paying online, banking app authorisation is part of the payment flow. Never irl. Probably using a VPN and a privacy email address increases the likelihood of this extra step being required.
Some features, such as card payment authorisation, aren't available through the web.
Gitworksho.dev is good for managing the issues but you can also create the issues straight from your app. Many clients support notifications for the discussion thread.
Definitely. We could iterate really quickly with a combination of reports (1984), WoT based metrics, relay based filtering and client side mantainer and user tools.
This is a good thought. Right now I feel we are too experimental and it would be counter productive to have a large influx of users with viral marketing.
nostr:npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc we should have a call sometime to discuss compatible. Would you be up for that? I reached out the other day on telegram.
hey, gittr.space has notification to telegram or nostrAre you sending a nostr DM from a system account for every one of these notifications?This feels a like an anti-pattern. Wouldn't it be better to show them as notifications in the gittr UI. Many clients show git related content in there notifications normally and as we grow #GitViaNostr maybe more will.
No not yet. https://gitworkshop.dev/notifications is a good place to see notifications for #gitvianostr
I'm a bit confused. Are you are saying the extra complexity of having lots of different ways of doing the same thing is OK? And that you made a PR to a project that has only 1 commit posted 2 years ago.
https://gittr.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr?file=docs here's with the blossom addition
nostr:npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc are you worried that supporting so may ways of doing the same thing, adds unnecessary complexity, makes it harder to understand and harder to implement?
Whats a blossom pack? is it related to the blossom pack idea i outlined in nostr:nevent1qvzqqqqx2ypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqqsg9w72dve9myu29swk7w9wapqncndnhe98dmfrrd8cjd26fy3lsgsnkqr9d
how are repositories mirrored via NIP-34 events? In NIP-34 git data is only stored on git servers. are you are storing the files in nostr events? Do you have a spec you are working towards that outlines the primatives you are using?
Jo, I include https://git.gittr.space/... as the primary clone tag on push by a new endpoint to the bridge so theres a guaranteed HTTPS source while it’s processing. Once other relays pick up the NIP‑34 event, the nostr:// URLs are broadcasted and should work. http://gittr.space/help#git-operations
Option C links to a repository that doesnt exist. ngit has the git-remote-nostr plugin that enables cloning via `nostr://` see ngit.dev/install
Jo, I include https://git.gittr.space/... as the primary clone tag on push by a new endpoint to the bridge so theres a guaranteed HTTPS source while it’s processing. Once other relays pick up the NIP‑34 event, the nostr:// URLs are broadcasted and should work. http://gittr.space/help#git-operations
I dont understand your recommended option. how can you use ssh? Are you offering a centralised git server permissioned via ssh keys?
Jo, I include https://git.gittr.space/... as the primary clone tag on push by a new endpoint to the bridge so theres a guaranteed HTTPS source while it’s processing. Once other relays pick up the NIP‑34 event, the nostr:// URLs are broadcasted and should work. http://gittr.space/help#git-operations
I don't understand how a bridge is a decentralised git server. Do you mean they are stored on grasp and access via a bridge for efficency?
Repo read is still done on the client for the events and the bridge fetch, so thats due to the storage/cache + binary fallback, not SSR.
Flow is described here https://gittr.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr?file=README.md
strategy 4 - files are never embedded in event content. isn't extracting the clone urls just strategy 3? You should look up the state event `30618` and if there is one trust that rather than the refs provdied by the clone urls. by the looks of it, 99% of files are going to be delivered from your bridge, so i guess that should happen there also.
Repo read is still done on the client for the events and the bridge fetch, so thats due to the storage/cache + binary fallback, not SSR.
Flow is described here https://gittr.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr?file=README.md
in strategy 3 grasp servers dont expose "/api/nostr/repo/files" or "/api/git/file-content?sourceUrl=". are you saying you have a bridge that servers the files over that API ie go to strategy 5?
Your making some fantastic progress on this and quickly. Can you fix your announcement event so it clones from the `nostr://` URL? Files in repos are loading really fast. Are you SSR them?
O cool. Do you mean until your confident your app won't create noncompliant NIP-34 kinds?