Nostr Web Client

Grasp is Blossom for git repositories.

You can host your repositories in multiple servers and their state is attested by Nostr events you publish that tells people where to fetch from and what is the latest head and branches, so the servers don't have to be trusted and it's easy to switch servers while keeping your repository identifiers immutable (they're essentially your pubkey + an arbitrary identifier).

Grasp servers can be self-hosted, paid, or ran for free by some community benefactor, and you can mix and use all these at the same time.

The existence of grasp servers also makes it easy for people to clone repositories, create branches and make them available to be merged by others, all without leaving the terminal (but of course there can also be all kinds of clients), which is the GitHub "pull request" UX people are familiar with.

Five 1mo ago

Full Grasp support coming to BudaBit soon, the primitives are already implemented.

1. What we struggled with is the creation flow where we first post the repo announcement then the newly created git repo, but that must be done with an arbitrary sleep(X ms) wait time so that's not really ideal.

You guys have ideas to improve this flow?

2. I think it this was discussed before but want to get a fresh opinion of yall: Unified grasp api for file browsing and perhaps diffs and really data-heavy ops? Cloning repos via git smart http can still be a fallback but this would benefit performance a lot. Blossom has an api as well so I guess this would make sense, especially in a browser context.

nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp nostr:nprofile1qqs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsq3camnwvaz7tmgv9mx2m3wv3skucm0demkz7tyv4mzucm0d5p6s74j

Reply to this note

Please Login to reply.

Discussion

DanConwayDev 1mo ago

For 1, the 5s timeout used in ngit was more of a placeholder for a better approach. I think its best to pole the repo endpoint every 200ms until it reponds as if the repo as been created.

Five 1mo ago

Good idea thanks!

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

consider the option of using REQ and subscriptions. they are so fast if clients randomly put my relay wss://relay.orly.dev/ later than other relays, it has already received it via subscription using the follows spider. i will follow up this note with a screenie of it happening, if it happens

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

nope, it didn't do it, lets see if it works this time

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

humbug, imwald is sending it to my relay first.

anyway, it happens now and then, i see in the upload popup on the bottom right, that if my relay doesn't get sent the event first, it returns that it already has it.

DanConwayDev 1mo ago

2. In the browser context we cannot rely on iso-morphic git as it doesn't support sparse clones and the UX of a shallow clone (with blobs) isn't good enough for large repos. eg. try browsing https://gitworkshop.dev/vitorpamplona.com/amethyst for the first time.

I think we should explore directly requesting a pack from the http endpoint containing the blobs we need (for a specific file) instead of relying on iso-morphic git. We could create a javascript library that does just this.

If this doesn't work then we should add an API endpoint for files / listing directories, etc. My concern about the API is 1) it enables the use of a grasp server as a CDN for files in a repository 2) where would we stop in terms of the API, there isn't a clear boundary and we could end of creating all git commands / options as an API which makes it a more complex protocol and harder to implement.

Someone nearly attempted to add sparse clone in iso-moprhic git but there are a baked in assumptions in may parts of the codebase that blobs are present so it would require a larger change and it might be hard to get merged as a first time contirbutor.