DanConwayDev

freedom tech developer and creator of ngit, https://gitworkshop.dev and https://metadata.nostr.com

Public Key

npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

NIP-05 Address

Profile Code

nprofile1qqs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq32amnwvaz7tm9v3jkutnwdaehgu3wd3skueqpz3mhxue69uhkummnw3ezummcw3ezuer9wcq3camnwvaz7tmgv9mx2m3wv3skucm0demkz7tyv4mzucm0d5tfqt3r

Publishing to

haven.danconwaydev.com

Author Public Key

npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

Show more details

Last Notes

2026-02-16 15:28:18 UTC

- reply

https://nips.nostr.com/34#repository-state-announcements

2026-02-15 10:27:51 UTC

- reply

What do you mean by 'where the clones are'? The clone URLs are listed in the announcement event. The actual protocol is the best place to look: https://gitworkshop.dev/npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/grasp

2026-02-14 21:51:16 UTC

- reply

Yes, the https://gitworkshop.dev/fiatjaf.com/git-natural-api approach is best way for a lot of scenarios where you want to display repo data.

2026-02-12 12:07:41 UTC

GLM5 is my new favourite model

2026-02-11 20:13:50 UTC

- reply

Another good roundup. I liked how you built on themes and tried to keep things moving and below the 15min mark.

2026-02-11 14:53:13 UTC

- reply

This is interesting. Does the comment still appear for you @nprofile…lej9 when you are logged in?

2026-02-10 21:25:08 UTC

- reply

Try pipepipe

2026-02-10 20:46:16 UTC

- reply

Nice round up. I like the format. It's nice to see what's peaking your interest.

2026-02-10 12:17:43 UTC

- reply

Where has git started using rust?

2026-02-09 17:01:04 UTC

- reply

Why lock your source control and collaboration flow to a single provider when you can use an open network with built in redundancy?

2026-02-07 23:01:08 UTC

- reply

FYI I plan to create a optional extension of the GRASP protocol that supporting relay based moderation that respects the wishes of maintainers. Examples include: 1) deletion - they can delete PRs, issues, comments etc. 2) apply WoT rules for creating issues, PRs or even comments. 3) optional pre-approval proeccess for PRs or Issues.

2026-02-07 22:52:15 UTC

- reply

Interesting! It feels like there is such an opportunity for #GitViaNostr with Microsoft neglecting github so much. If they were on the ball, they would have introduced a feature like this months ago.

2026-01-27 10:45:15 UTC

- reply

Yes your right. The output of those different phases should be consolidated so you just see the status per relay / git / grasp server.

2026-01-22 14:27:51 UTC

I totally agree. Unless you need dowload every file in a repository for some reason this is much better. It uses a fraction of the bandwidth and is really quick.
#nevent1q…asgg

2026-01-20 19:36:39 UTC

- reply

I thought about doing this to make @nprofile…cd2e's favourite and @nprofile…xuyp 's least favourite client at the same time

2026-01-20 11:35:49 UTC

Fantastic to see this coming together
#nevent1q…lgfa

2026-01-17 08:51:56 UTC

- reply

So your needs are: 1) basic Issue / PR flow with good review tooling 2) moderation tools 3) CI tooling? Have I missed anything?

2026-01-17 08:23:50 UTC

- reply

With ngit, nostr events are synced to a db within the .git directory. Also GRASP-05 enables archive servers that mirror repositories the operstor cares about. This enables repository data to always be publically available even if the services the maintainers choose go down.

2026-01-16 21:37:12 UTC

- reply

As @nprofile…3zgd said you can use any git server you want or host it yourself. Grasp is designed to enable users and projects to either self host, use grasp services offered by individuals or teams in their network or use public free or paid servers. The idea is thst projects use multiple grasp services at the same time whic sync up to provides reduncancy. Its also really simple for maintainers to switch service providers by updating a single event.

2026-01-16 21:23:15 UTC

- reply

quote from https://radicle.xyz/guides/seeder :
"While a peer-to-peer network without seed nodes is feasible, it is impractical. This is because regular “user” nodes go online and offline all the time, so finding a user from which to download a certain piece of content can be challenging, or even impossible if all users with that content are offline. Therefore, a healthy peer-to-peer network necessitates at least some highly available nodes that participate in the network like regular peers, but seldom go offline. These are called seed nodes."

2026-01-16 21:22:06 UTC

- reply

last time i checked in on the project it mainly worked through 'seed' nodes which are analogus to relays because p2p was proving so unreliable. I'm not sure how much more decentralised it is in reality.

2026-01-16 21:18:29 UTC

- reply

Hi @npub185h…wrdp, I'm the creator of gitworkshop, gnit and grasp. A combination of relay an client tools can provide the provide this sort of moderation and control for projects that desire it, but the maturity of git nostr isn't really there yet. Whilst the majority of a project community would likely use these tools that support this moderation, the conversation can spill over into the wider nostr ecosystem and clients built / used that don't enforce this moderation. This is the trade-off using an open protocol thats easy to build on.

2026-01-06 21:23:42 UTC

- reply

How's the gnostr stuff going?

2025-12-27 12:51:37 UTC

- reply

In my proposal there are multiple packs relating to groups of commits in the history so the hashes don't change. Uding ^2 exponential.

2025-12-27 12:05:10 UTC

- reply

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.

2025-12-27 11:57:53 UTC

- reply

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.

2025-12-27 11:54:59 UTC

- reply

@nprofile…ptz7 I considered using blossom, in fact I even wrote some code. #nevent1q…x4r0 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.

2025-12-23 15:07:57 UTC

- reply

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?

2025-12-23 13:53:53 UTC

- reply

I'm not seeing that comment.

2025-12-23 10:50:46 UTC

- reply

This is because a git repository can't be found at the git.gitter.space address listed in the announcement. @nprofile…cy97?

2025-12-22 21:49:46 UTC

- reply

How was the process?

2025-12-22 21:49:06 UTC

Let every client be a git nostr client
#nevent1q…s9j2

2025-12-22 21:01:15 UTC

- reply

ask and you shall receive
#nevent1q…ryvq

2025-12-21 09:16:39 UTC

- reply

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.

2025-12-19 16:51:32 UTC

- reply

Some features, such as card payment authorisation, aren't available through the web.

2025-12-19 14:49:11 UTC

- reply

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.

2025-12-18 21:08:33 UTC

- reply

I needed to hear that. Thanks.

2025-12-18 19:30:02 UTC

- reply

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.

2025-12-18 16:59:30 UTC

- reply

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.

2025-12-17 16:27:20 UTC

- reply

@nprofile…cy97 we should have a call sometime to discuss compatible. Would you be up for that? I reached out the other day on telegram.

2025-12-17 16:16:53 UTC

- reply

Are 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.

2025-12-17 16:09:19 UTC

- reply

No not yet. https://gitworkshop.dev/notifications is a good place to see notifications for #gitvianostr

2025-12-15 20:13:06 UTC

- reply

Yes, I'll add it with a left-pad protection scheme.

2025-12-09 14:25:18 UTC

- reply

I cannot replicate this on 145.0. vnext.gitworkshop.dev is now at the exact same state as gitworkshop.dev. does it now have the same behaviour? does a fresh profile fix it?

2025-12-09 09:57:49 UTC

- reply

I think your missing the insight into fucundious nature of ground of our being. These life-like properties are emergent in 146 bytes of C: `#include<stdio.h>
#include<stdlib.h>
int main(int c,char**v){int i,j;for(i=1;i<c;i++)for(j=1;j<c-i;j++)if(atoi(v[j])>atoi(v[j+1])){char*t=v[j];v[j]=v[j+1];v[j+1]=t;}for(i=1;i<c;i++)printf("%s%c",v[i],i==c-1?'\n':' ');}`

2025-12-09 09:18:51 UTC

Michael Levin's team applied 'theory of life' analysis to a sorting algorithm and found emergent life‑like behaviors not explicit in the code — including delayed gratification, clustering, robustness, and repair. Fascinating.
https://www.youtube.com/watch?v=Qp0rCU49lMs

2025-12-08 23:13:46 UTC

- reply

I made it a PWA a month or so ago, clearly not as successfully as I thought.

2025-12-08 23:12:23 UTC

- reply

So you're getting this too?

2025-12-08 23:11:52 UTC

- reply

Does this happen I'm a fresh profile? I'll try it on this version but I suspect there is something else being cached somehow that's causing this issue.

2025-12-08 21:06:19 UTC

- reply

I can't replicate this. I also tried rolling back and forwards with various with a dev preview and couldn't replicate any issues. What Firefox build are you using? I've tried librewolf and 145.0.2. Can you replicate it on gitworkshop.dev now even after you unregister the old service worker? Does it also happen on vnext.gitworkshop.dev?

2025-12-08 18:17:01 UTC

- reply

Thanks. I've actually justed picked this message up now (i somehow misted your note from 3 days ago) and I'm afk. I reproduced it in chrome based on the troublesome build I mentioned. I'll try and reproduce when I can get back to the keyboard.

2025-12-08 18:00:56 UTC

- reply

#nevent1q…xcdk

2025-12-08 17:49:45 UTC

- reply

@nprofile…6akr thanks for the report. I thought this white page issue was related to a tempory PWA corruption I introduced for users who visited the page during a windows of a few hours when I initially introduced it. I can see now this is happened on persistently on Firefox. I'll look I to this in a few hours.

2025-12-05 22:43:16 UTC

- reply

For now you can just ask in the chat box to commit your changes and the AI will do it for you. Then you can use the 'Push to Nostr' button.

2025-11-29 17:24:47 UTC

- reply

For now if you want you check the network tab of developer tools and filter for websockets to see the request and events that come back. State event is kind 30618

2025-11-29 17:23:11 UTC

- reply

This means it can't find the state event on the relays specified in the announcement event. Clearly this warning should specify that and yrll you which relays it checked and either it failed to connect, got rate limited or didn't have the event. I'll make this better

2025-11-29 10:22:10 UTC

- reply

@nprofile…evew the rust developer

2025-11-28 01:27:03 UTC

- reply

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.

2025-11-27 20:46:21 UTC

- reply

It turns out that the http wrapper (CGI scripts) is not that complicated. There are nearly 3 grasp implementations that do this bit internally. This enables shipping a single binary and handling the authorisation *before* the data is sent.

2025-11-27 20:40:46 UTC

- reply

I'm sure the midcurve meme apply here with 'just let git handle that'.

2025-11-27 20:38:59 UTC

- reply

The reference implementation does exactly that. It uses nginx to pass request to the git-http-backend CGI scripts maintained by the git project.

2025-11-27 20:24:52 UTC

- reply

Nice! Would love to see it.

2025-11-27 20:23:28 UTC

- reply

The problem is git enables many feature like shallow and parse cloning, packing specific object and data, getting specific files and git logs, etc. These are all battle tested on solid git server implementations. This is all not possible trying to reinvent a simplified git server with blossom.

2025-11-27 19:46:16 UTC

- reply

@nprofile…cy97 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?

2025-11-27 19:43:33 UTC

- reply

Interesting. You'd end up with a lot of objects with that approach and eventually it would be too big for the event size. I thought about doing it with storing packs in blossom. Here is my code to play with that idea. https://gitworkshop.dev/danconwaydev.com/ngit/prs/note1s2au56ejtkfc5tqaduu2a6zp83xm80j2wmkjxx603y645jfrlq3qmp88s4 I would have made it into a POC if rust-nostr had blossom support at the time. It does now. It turns out that having a git server is way more flexible so ngit.dev/grasp came to be. Let git be git and let nostr be nostr.

2025-11-27 14:40:56 UTC

- reply

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.

2025-11-27 14:27:22 UTC

- reply

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.

2025-11-27 13:59:26 UTC

- reply

tbh I'm not all that happy that a human readable string is part of the repo id. even though there is a seperate 'name' for a repository, people still want to change the human readable bit of the ID and to do so are prepared to leave behind the repo and start again with a fresh ID.

2025-11-27 13:37:20 UTC

- reply

Is your Grasp critique largely around repository discovery?
I think I addressed your concerns about auth and availability:
AUTH to nostr instead of AUTH to server.
GRASP-02 for proactive sync for better availablity (also client help to sync git data across grasp servers)

2025-11-27 13:18:40 UTC

- reply

Do you mean in relation to finding a repository? Nostr repositories use human readable repo identifier within a npub namespace. This leverages WoT based search. There is a lot of work to do make this work well, but I see a path to success for this.

2025-11-27 13:10:37 UTC

- reply

GRASP-02 (proactive sync) will sync git and nostr events related to accepted repositories from other repository relays / git server listed by maintainers in their announcement event.

2025-11-27 13:05:20 UTC

- reply

What do you mean by a directory? Relay discovery for repositories?

2025-11-27 12:31:31 UTC

- reply

why does it need consensus? The state is embedded in an addrssable nostr event and you can probabilistically know whether the state you have is the latest based on your connectivity to relays and the trust trade-off you have with them that they are going to accept and timely serve you the maintainers events. This is a well established pattern in nostr.

2025-11-27 12:19:53 UTC

- reply

The design for grasp is to authorise actions across nostr, not for particular relays one by one. This way we are minimising trust in relays and allow uses to mirror a repository fully without having to trust other relays / servers. The full authorisation lives fully in public.

2025-11-26 19:34:58 UTC

- reply

1984 reports on kind 0 event id (not naddr) generated and consumed automatically by clients?

2025-11-26 11:06:41 UTC

- reply

Whats a blossom pack? is it related to the blossom pack idea i outlined in #nevent1q…qr9d

2025-11-26 11:02:00 UTC

- reply

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?

2025-11-26 10:57:11 UTC

- reply

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

2025-11-26 10:54:07 UTC

- reply

I dont understand your recommended option. how can you use ssh? Are you offering a centralised git server permissioned via ssh keys?

2025-11-26 10:49:08 UTC

- reply

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?

2025-11-26 10:45:40 UTC

- reply

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.

2025-11-26 10:41:02 UTC

- reply

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?

2025-11-26 05:18:43 UTC

- reply

I've stopped using it as my daily driver. I found version upgrades required quite an investment in time and their perfered approach to declarative config kind of sucks. I now use nixos and i try and compartmentalise as much as possible. https://github.com/CertainLach/nixos-qubes looked really promising and it looked like they were making a lot of progress really quickly but they seem to have abandoned the project 9 months ago.

2025-11-26 05:13:00 UTC

- reply

I can only read it through secondary sources. How (not) to speak of God by Peter Rollins had a profound impact on my faith.

2025-11-26 03:09:32 UTC

- reply

Impenetrable?

2025-11-26 03:05:58 UTC

- reply

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?

2025-11-25 03:37:16 UTC

- reply

You have a strange way of tagging my pubkey.

2025-11-25 03:36:37 UTC

- reply

We are still doing it! Maybe signaling 34 is a good idea to for those not looking at `supported_grasps`.

2025-11-21 02:50:39 UTC

- reply

Did you try the https URLs directly after the nostr one or did you come back to it a bit later?
I'm wondering whether it was a coincidence or whether the git plugin is less resilient when it comes to connectivity issues.

2025-11-20 18:36:16 UTC

- reply

O cool. Do you mean until your confident your app won't create noncompliant NIP-34 kinds?

2025-11-20 17:02:11 UTC

- reply

You experienced a timeout issue. I could clone the repository without any problems. Can you try cloning again. Your repository clones fin both gitnostr.com and realy.ngit.dev timed out. I control both of these and really need to sort out some better performing infrastructure for them.

2025-11-20 16:59:34 UTC

- reply

We have that as a `10317` user grasp list, modelled on the blossom version was merged into NIP-34 as part of the PR event nip PR in commit 2aaba90839443dded18afb10adea5806904ea04f.
Also we have the 'personal-fork' tag in an announcement (see same commit) to differenciate these sort of announcements.
Why is https://nips.nostr.com/34 not reflective of the github version?

2025-11-20 16:37:44 UTC

- reply

Welcome to the Git Nostr community! Its great to see you are building and that you're building on the existing work in the space.
It looks like you may have started with a fork of an early git nostr project that created a github like UI that had ideas about intergrating https://github.com/spearson78/gitnostr which emerged at the time and but was quickly abandoned. I see with gittr you have taken that idea and run with it and also began to try and reconcile / add / intergrate new Git Nostr invovations such as GRASP with spearson78 approach. I'm not sure how easy that would be as they don't appear to be compatible. The active work in Git Nostr space all seems to be based on NIP-34. Would you consider change gears towards NIP-34 / GRASP for greater compatibility with the ecosystem?

2025-11-20 14:32:18 UTC

- reply

It took me much longer than I anticipated to Implement PRs in ngit because its hard to get a good UX. If you cant write to the repositories grasp servers (or they don't list any) you have to write to another grasp server. This involves selecting a grasp server (which is hard to do without hardcoded defaults, although WoT based 'user grasp list' is possible but filtering based on whether they are likely to accept your data might a challenge). Then it needs to send a repo annonucement with a 'personal-fork' tag (to prevent it from appearing like you own the project) and push the entrire repo there. If its a big repo that could be 1gb push.
Once there are more (and reliable) grasp servers available and most nostr git repositories are primarily using them I think it will work much better.

2025-11-20 14:20:35 UTC

- reply

PR events sit completely parallel with patches. I considered whether grasp servers should accept patch git data as refs/nostr/<patch-event-id> or even generate the ref when patch events are received.
For:
1. clients that choose just to implement only PRs could easily extend to add basic support for patches by treating them as PRs (root patch map to the PR event and additional patches map to PR updates but follow nip10 rather than nip22).
Against:
1. it encourages clients not to implement applying patches
2. patches not sent to a grasp server wouldn't show up in these clients. Showing some but not all is bad UX.
3. patches not accepted by the repository grasp servers wouldn't show up (there are no grasp server hints like in PR events).
4. its another thing for grasp servers to implement

2025-11-20 13:55:38 UTC

- reply

That all makes total sense. Reacting to a repository isn't and shouldn't be the same as following it.

2025-11-20 13:40:35 UTC

- reply

You CTRL-C exited the interactive `ngit init` command before publishing the event. `? repo name (keyboard) > ` is a prompt for the name of the repo, defaulting to 'keyboard'. So press enter to continue.

2025-11-20 13:27:13 UTC

- reply

No! At the risk of duplicating the conversation on the NIP PR @npub180c…h6w6 just opened:
In #nevent1q…n332 I proposed we should add a Git repository 'set' with a default d=starred that acts as a follow list.
but maybe a 'standard' NIP-51 git repository follow list like that PR suggests is better. Would / should clients label this list as starred repositories? I think may git clients will want to inherit the 'starred' concept from github but I there is an overlap with reactions, zaps and a repository follow list.
We should definately add git repositories as a set.
BudaBit is using lists for git repositories so we should also build on their work @npub1ehh…zjqv @npub16p8…fhdw.

2025-11-20 13:02:38 UTC

- reply

This UX needs to be tightened up. Maybe it should detect that the signed in account is attempting to push to a repo that they have been added to as a mantainer and auto accept the invite (issue an announcement event listing the other maintainers) before completeing the push.
also have a GUI to manage this eg in gitworkshop this would be nice.

2025-11-20 02:27:27 UTC

- reply

I don't know why it was effecting this repository and not others