DanConwayDev

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

Public Key

npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

NIP-05 Address

[email protected]

Profile Code

nprofile1qqs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngpp4mhxue69uhkummn9ekx7mqtttt5c

Publishing to

nos.lol

Author Public Key

npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

Show more details

Last Notes

2025-03-27 09:33:23 GMT

- reply

@npub1jlr…ynqn's attempted at defining this in this nip27 PR: https://github.com/nostr-protocol/nips/pull/1800

2025-02-17 22:25:13 GMT

- reply

Thanks for expressing interest. Here is a link to a GitViaNostr simplex group. I'll try and arrange a Signal call later this week to outline the categories of GitViaNostr projects and explore opportunities for collaboration. Dont worry if you can't make the call, we can follow up afterwards.
https://simplex.chat/contact#/?v=2-5&smp=smp%3A%2F%2F1OwYGt-yqOfe2IyVHhxz3ohqo3aCCMjtB-8wn4X_aoY%3D%40smp11.simplex.im%2Fh4qUr9Yj8C9y59CoalGVQDQWpEPzESmW%23%2F%3Fv%3D1-2%26dh%3DMCowBQYDK2VuAyEAltJo8QZNzjq_6Sz_zjMqY3Sqb9Jg2mSiDIAvSIUg9kA%253D%26srv%3D6ioorbm6i3yxmuoezrhjk6f6qgkc4syabh7m3so74xunb5nzr4pwgfqd.onion&data=%7B%22type%22%3A%22group%22%2C%22groupLinkId%22%3A%223WlWt7YVg49I_AcPMLgQFQ%3D%3D%22%7D

2025-02-17 13:03:28 GMT

- reply

I tested multi-account nip07 functionality. Right now this works in the same way NoStrudel does. Its intuitive if you switch accounts in the signing extension and the app at the same time, but it otherwise gets confusing as account switching with the app and within the extension happen independently. cc @npub1ye5…knpr.
To improve this, the app could ask for the pubkey on page load (or refresh) when a nip07 extension user is logged in. Then it could switch the user to the active pubkey.
This would be slightly annoying for unusual users like me who likes to manually approve each signing request but its probably worth the trade off.
This wouldn't pick up on changes if the nip07 signer account changed whist the app is already loaded. Periodic polling of the signer pubkey could address this but this would be even more annoying for users who want to manually approve.

2025-02-16 13:22:44 GMT

- reply

Yes, sorry I was being pedantic. It's cool isn't it?

2025-02-15 00:58:24 GMT

- reply

Thanks again Ben. I indeed added apple-sauce signing but havn't gotten to the nip46 or Amber clipboard signing just yet. There is an issue open for it. Your welcome to have a go? I can provide some guidance as needed.
#note1vpd…s2p6

2025-02-15 00:20:40 GMT

- reply

We should prioritise this as its a quick win.

2025-02-14 23:30:08 GMT

- reply

sure thing Pip!

2025-02-14 22:46:48 GMT

- reply

this is important and a key priority once the rewrite is stable and out of pre-release.

2025-02-14 22:44:44 GMT

- reply

I'll try and facilitate and help organise some collaborative working on #GitViaNostr projects. I'll arrange a dev call next week. Let me know if your interested. Thank you to those who have already contributed / expressed interest, I'll be in touch.

2025-02-13 23:43:04 GMT

- reply

I like daisyui

2025-02-13 06:52:07 GMT

- reply

I'm keen to collaborate on this with anyone interested

2025-01-29 09:38:43 GMT

- reply

unfortunately, the only unified way of doing it is by cloning the repo. Someone made a WASM compiled wrapper for gitlib2 for the browser so I plan to try shallow cloning in the browser.
For now I'm doing the below. I'm no longer going through a proxy so I hit a CORS error for most hosts. github also rate limit so you might encounter that when debugging.
From commit 19471e7c190cab4f2f823fb4e279066c5e211c5f
```typescript
/** most servers will produce a CORS error so a proxy should be used */
export const cloneArrayToReadMeUrls = (clone: string[]): string[] => {
const addresses = clone.map(extractRepoAddress)
/**
* at the time of this commit these urls work for:
* self-hosted gitea (or forgejo), gitlab
* github.com
* bitbucket.org
* gitlab.org
* gitea.com
* codeberg.org (forgejo instance)
* sourcehut (git.sr.ht)
* launchpad.net
* It doesnt work for:
* self-hosted gogs (requires branch name repo/raw/master/README.md)
* sourceforge.net (https://sourceforge.net/p/mingw/catgets/ci/master/tree/README?format=raw)
* notabug.org (requires branch name notabug.org/org/repo/raw/master/README.md)
*/
return [
...addresses.flatMap((address) => {
let prefix = 'raw/HEAD'
if (address.includes('sr.ht')) prefix = 'blob/HEAD'
if (
address.includes('git.launchpad.net') ||
address.includes('git.savannah.gnu.org')
)
prefix = 'plain'
if (address.includes('github.com')) {
// raw.githubusercontent.com can be used without CORS error
address = address.replace('github.com', 'raw.githubusercontent.com')
prefix = 'HEAD'
}
return ['README.md', 'readme.md'].map(
(filename) => `https://${address}/${prefix}/${filename}`
)
}),
]
}
const extractRepoAddress = (clone_string: string): string => {
let s = clone_string
// remove trailing slash
if (s.endsWith('/')) s = s.substring(0, s.length - 1)
// remove trailing .git
if (s.endsWith('.git')) s = s.substring(0, s.length - 4)
// remove :// and anything before
if (s.includes('://')) s = s.split('://')[1]
// remove @ and anything before
if (s.includes('@')) s = s.split('@')[1]
// replace : with /
s = s.replace(/\s|:[0-9]+/g, '')
s = s.replace(':', '/')
return s
}
```

2025-01-24 19:49:59 GMT

- reply

What's the status of accounts and signer packages? Has the relivant nostrudel code been moved into applesauce?

2025-01-22 10:07:04 GMT

- reply

nostrbrite.com is looking great. keep up the good work.

2025-01-18 22:15:39 GMT

- reply

O yeah!

2025-01-14 12:20:13 GMT

- reply

This is fanatic!

2025-01-06 19:46:08 GMT

- reply

Were you and your wife's gift given expectations aigned?
#nevent1q…tgvw

2024-12-31 10:14:40 GMT

- reply

2024-12-20 21:14:31 GMT

- reply

Only if users get notification in their daily driver clients. Otherwise the conversations die and move to a channel where participants do get notifications.

2024-12-20 17:46:53 GMT

- reply

I'm the author of gitworkshop.dev and ngit. I like your vision. Let's talk!

2024-12-20 15:41:07 GMT

nostr on-boarding flows are hard
#nevent1q…xcsp

2024-12-20 15:40:17 GMT

ngit v1.6 (beef-up onboarding) released with improved on-boarding and login flow.
Thanks to new contributor @npub1elt…cume who added nip05 address support to nostr git clone url.

2024-12-14 19:12:43 GMT

- reply

I look forward to hearing if gift giving expectations were fully aligned! How do you mark Epiphany? Its not a part of our tradition at all.

2024-11-27 12:36:46 GMT

- reply

I've never seen issues shown in a main feed
Which client were you using?

2024-11-18 16:49:03 GMT

- reply

here you go @npub1elt…cume. I didn't build any dummy binaries to test it with, so don't expect it to work yet or anything.

2024-10-10 17:59:51 GMT

- reply

i3. simple. flexible. powerful.

2024-09-25 15:48:15 GMT

- reply

closing due to inactivity and user didn't back to confirm whether it is still a problem.

2024-09-24 19:10:33 GMT

ngit v1.5.2 released. download from https://gitworkshop.dev/
- login via nip46 QR code
- enable login directly in git plugin
- add resilience to git plugin so that a poorly formatted prs gracefully fail and won't cause issues elsewhere

2024-09-20 06:43:33 GMT

- reply

I'd prefer to include ecash in requests than to auth

2024-09-19 12:31:12 GMT

- reply

Thanks

2024-09-17 14:00:42 GMT

- reply

this does look right but isn't it a link to wiki article rather than a proposal?

2024-09-13 15:41:07 GMT

- reply

I have fixed this on the master branch. I'll push a v1.4.6 shortly to patch v1.4.
with the fix your branch could be called `article-editor` or `pr/article-editor`
if you are logged in as the author of the PR (git config nostr.npub matches the PR author)
or `article-editor(3fbba0ec)` which is what it would be named if you weren't logged in as the author and checked out the branch on a remote with the nostr url.
I think there might be other problems with the repo (potentially stemming from oversized patches). Hence the need for blossom for large patches and the discussion we were going to have.

2024-09-11 08:49:52 GMT

- reply

Yes. I think I've mentioned it before but I'm planning on using blossom as a fallback for large commits that result in events that are so big relays won't accept them. I think this is the bestway of doing it without relying on the contributortoo indefinitely host a git server with the patch on it. This does add complexity and depending on how it was handled in the interface, effect other NIP-34 clients as they may no longer be displaying all PRs submitted unless they add at least partial support.
I'd love to get the input from your team on this. Could I join one of your dev calls to discuss it with you?

2024-09-11 08:24:29 GMT

- reply

I think so. I'm still open to the idea as repos will opt-in this if there continues to be demand. There is a growing list of things that are higher priority right now.

2024-09-03 09:58:53 GMT

- reply

there are a few usecases here: 1) discovery of new interesting content on git 2) notifications of content I have indicated I'm interested in; and 3) Inbox style - messages I definitely need to be looking at.
I'd like there to be experiences for all three on GitWorkshop.
I completely agree that notifications just for git related things is needed.
I haven't forgotten about this as a more PR focused inbox for ngit is also important
#nevent1q…wzx7
I'm reminded of the workflow of Greg Kroah-Hartman as discussed here https://www.youtube.com/watch?v=vyenmLqJQjs and how CLI tools (eg ngit) could aid in the workflow of maintainers.

2024-09-03 08:15:15 GMT

- reply

Here's the client I work on: https://gitworkshop.dev

2024-09-02 14:33:18 GMT

- reply

Here is a suggestion for updating the nostr:// git standard based on needs emerging from usage:
nostr://ssh/npub123/relay.damus.io/my-repo
nostr://npub123/my-repo?relayhint=relay.damus.io&server-protocol=ssh
nostr://naddr123*
*no support for specifying server protocol
note that `git clone nostr://...` will name the directory with anything after the final `/` unless a directory name is specified.
I personally think the first format has the best balance of conciseness and readability. To articulate it more precisely, rather than by example, it is:
`nostr://<optional-protocol/<required-npub>/<optional-relay>/<optional-relay-2..n>/<required-identifier>`
I'd love some feedback before implementing. @npub180c…h6w6 @npub16r0…z5pl @npub16r0…z5pl @npub1upl…sfek @npub1s3h…75wz

2024-08-27 11:24:19 GMT

- reply

Yes this is cool. I'm concerned about the privacy implications of WoT and super excited about the possibility that znp brings to the table. We need to implement it in our apps so it get normalised in nostr dev practice.

2024-08-26 13:54:57 GMT

- reply

basically you can add a query parameter with 'relay' in the name and it will decode the value. this way multiple relays can be specified. to prevent ugly encoding of characters like :// affecting the readability it will assume the wss protocol unless ws is specified.
this seems all seems a bit loose to me and may lead to clients producing urls that look different.

2024-08-20 12:08:13 GMT

#GitViaNostr just got 10x easier with a git plugin included in ngit 1.4
clone with a nostr url. any branch prefixed with `pr/` is an open proposal on nostr.
submit it to as a proposal via nostr by pushing a branch with a `pr/` prefix.
see https://gitworkshop.dev for a quick start guide
I'd love feedback

2024-08-02 22:34:12 GMT

- reply

I also tried publishing a new version of the event to no avail

2024-07-30 08:35:13 GMT

- reply

I compiled from master after having a quick scan of the code that touches the nsec, as like others, I don't like entering my nsec.
I'm getting this error.
```
Releasing ngit cli app...
✔ Fetched metadata from Github
ERROR RangeError: Value not in range: 1
#0 _RegExpMatch.group (dart:core-patch/regexp_patch.dart:95)
#1 GithubFetcher.fetch (package:zapstore_cli/commands/publish/fetchers.dart:78)
<asynchronous suspension>
```
with:
```yaml
ngit:
cli:
identifier: ngit
name: ngit
repository: https://github.com/DanConwayDev/ngit-cli
artifacts:
ngit-aarch64-apple-darwin.tar.gz:
platform: macos-aarch64-darwin
executables: [ngit-aarch64-apple-darwin/ngit]
ngit-x86_64-pc-windows-msvc.zip:
platform: windows
executables: [ngit-x86_64-pc-windows-msvc/ngit]
ngit-x86_64-unknown-linux-gnu.tar.gz:
platform: linux-x86_64
executables: [ngit-aarch64-apple-darwin/ngit]
```

2024-07-24 16:26:26 GMT

ngit v1.3.0 released. download from https://gitworkshop.dev
highlights: offline use and sign in from your android phone using Amber
shout-outs: @npub1w4u…0jr5 for Amber and @npub1drv…seet for rust-nostr
change log:
- NIP-46 remote signing (from Amber, etc)
- `list` breaks down proposals by status
- local cache in `.git` to enable viewing proposals offline and reuse by other git clients
- introduced `fetch` to download recent proposals
- improved repo selection and handling of multiple maintainers
- unqiue branch names for proposals to prevent name conflicts
- login to different npubs for different repositories
- store login details in git config so they can be reused by other git clients ran locally
- add NIP-31 alt tags to events
- add euc marker per NIP-34 tweak
- fix: ensure repo events of all maintainers are tagged in proposals
- fix: stop filtering out very large patches

2024-07-04 06:25:59 GMT

- reply

Are you self-hosting or using a hosted version like codeberg? Did you find it easy to port your CI/CD?

2024-07-03 18:39:55 GMT

- reply

I see the maintainer role as quite different to the contributor role. Maintainers decide which changes get applied to an application and make it into each release whereas contributors propose and / or code the changes. Often maintainers also review for quality but this is also sometimes left to contributors theough peer review.
The fabrication argument applies to the contributiom rather than maintainership.
In my above example the 3 maintainers could decide to create a key pair specifically for releases and share it amoung one another. It could issue the app profile event and each release. This seems to make the most sense if users are going to subscribe to a single app profile per application for releases.
What happens if one of the maintainers moves on? may be there is a falling out or they start working on the closed-source competitor. They will still know the signing key.
If however, app profiles supported maintainers each of them could create their own app profile from their existing pubkey, leveraging their own reputation, and include the others as maintainers. excluding the maintainers field, the app profile for this group would be the most recent one submitted by any of them. Any releases issued would be on behalf of the group. The membership of this group can evolve.
This is the best case I can make for adding a maintainers field.
I would prefer to follow an app profile published by a group of specific pubkeys with their own reputation who claim to maintain an app than a single pubkey who's ownership is opaque.

2024-06-04 07:59:07 GMT

- reply

I'd like to make a nostr git remote helper that will update a state event and push to multiple git servers listed in the announcement event

2024-05-30 19:52:29 GMT

At a restaurant this evening my daughter was being sick into my cupped hands just as, 4-feet away, some marketing-exec-type was having an Instagram moment

2024-05-14 05:56:08 GMT

- reply

Has this happened again for you?
There was probably some error sending the event and the error reporting / handling isn't so good.
I really like how no-strudel handles this. I need to look into how best to handle this using ndk.

2024-05-10 19:44:26 GMT

- reply

I noticed you have talked about it quite a lot. Have you had many objections to the idea?

2024-04-24 16:06:07 GMT

- reply

I love your use of the term stargazers. Here is my code review:
## Stores and Structure
The data can be more flexibly used if stored in a `stargazers` hex-pubkey string array parameter of `RepoEvent`, `RepoCollection` and `RepoSummary` in `components/repo/type.ts` rather than in a dedicated store.
For example it creates the opportunity to inlude them on repo cards in the Latest Repositories of the homepage.
The code to fetch the data could be moved into a `fetchStargazers` function and called in `ensureRepoCollection` in `stores/repos.ts` on line 96.
I just abstracted out `fetchReferencesBy` to make `repos.ts` easier to read and so that it could be used as a model for `fetchStargazers` in commit 24427e1682d56eed07913df8383b248f95cf92af.
## Stargazers Event Kind and Format
instead of a nip51 'standard list' with a custom kind, what about a nip51 'set' with the kind `30618` which is repo_event_kind + 1?
`30618` could be the kind for all curated lists of `30617` repositories and a `d` identifier of `stared` could be used for this instance.
## UI integration
It looks great to have stars shown, doesnt it?
Gitworkshop uses daisyui which provides consistant theming for buttons. checkout daisyui, or some of the other buttons to see the classes
Maybe the star button could show many current stars? tweaking this and how it is diplayed can come later.
Thanks so much for contributing.

2024-04-21 09:06:31 GMT

- reply

That seems like an inelegant work around. What happens when the readme needs an update?
Using a parametrised replaceable event would be slightly better but then @npub1494…zmp0 would need to maintain the readme in two places.

2024-03-20 11:10:08 GMT

- reply

Yes. I guess it still is the bad sort of bureaucracy as every change doesn't need to be peer reviewed in this sort of project.

2024-03-04 07:40:08 GMT

- reply

I also get that feeling. should I really be able to be naughty and someone's issue on a project I don't maintain? I have considered restricting it to just 1) user who raised the issue and 2) repo maintainers (OPTION 1).
then I thought that complexity shouldn't be added to the protocol to solve potential problems that haven't manifested. this has to be traded-off against the adding to the protocol when other have started to implement it. This thread illustrates how this annoys developers and leads to partially implemented NIPs: #nevent1q…dc6x
So what is the problem with being able to change a status on an issue or proposal I didn't create on a repository I don't maintain? I think it is:
1) malicious actors who change statuses to create chaos (SPAM status events) - couldn't this be dealt with like other SPAM?
2) users who, operating in good faith, close or reopen an issue / proposal but don't understand the maintainers approach, or wider context around why this sort of issue / proposal should remain closed. perhaps there could be the option to add a 'locked' hashtag which means future status events from non-maintainers should be ignored (OPTION 2)?

2024-01-29 22:14:55 GMT

- reply

Did you post the link using a standard social nostr client? Rather than a ngit or a gitstr with their special event type inviting patches?

2024-01-25 16:48:27 GMT

https://image.nostr.build/4dccab32e17a36f93f0192cfff0844a91166dc3bbbfdca676c03aa6e1e8c325e.png I've been working on a GitHub alternative over nostr.
https://gitworkshop.dev

2023-05-04 09:09:25 GMT

- reply

Is your intention to build something that other people would use or for personal use?
At the moment I think the direction @npub1xts…kk5s and seem to approve of is using the patch model. Everything else appears not to be fleshed out.
I think the patch model doesn't scale but is a good starting point because of it's simplicity.
I am not used to working in public either. There hasn't been any engagement with my long form posts on the issue. No one has commented on my draft NIP. My plan is to build a prototype and put it out there.

2023-04-28 09:27:02 GMT

- reply

the standard commands must be supported. Clone, pull and push could all be abstracted through a wrapper that receives and sends only patches over Nostr.

2023-04-23 19:19:37 GMT

- reply

#[4], Do you think its time to say goodbye to the blue/purple check for NIP-05 addresses? I make the case for it here: https://blogstack.io/naddr1qqyxxwf4vccnwcmrqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsyg9qpr00z4uklw56p4h6kp8gl4ts3y59m874qhd94ql732k40g6kf5psgqqqw4rshy3kcn

2023-01-25 22:47:25 GMT

The elegant way bitcoin resists censorship. A short article by DanConwayDev. Only on nostr:
Bitcoin is freedom money. Part of what this means is that it is money for enemies. This is made possible because bitcoin is censorship resistant. From Satoshi's first transaction with Hal Finney to the latest donation my alter-ego just made to Elizabeth Warren's BTC Pay Server. No valid transaction with a fee above the market rate has ever failed to make it into a block.
Part of the beauty of bitcoin's design is that it achieves this in a freedom maximising way. It's super elegant. Let's say I'm a miner and a little bit of sick just came up at the thought of being knowingly responsible for facilitating an Elizabeth Warren donation. No problem! I can elect to include or exclude whatever transactions I want from the next block I am mining. If someone told me her xpub I could censor away to my hearts content and still sleep easy tonight.
The thing is, my alter-ego is not a fee-cheapskate. The transaction will get included in the next block by other miners who are compelled by financial incentives. Yet my censor-loving self can drift off into peacefully sleep; freed from culpability.
Let's suppose I'm not the only censor-loving miner and 90% of the hash rate on joins in. Even then, when I undertake my morning ritual of perusing the mempool over a cup of earl grey, I will still find that the transaction has confirmed overnight.
If every miner, except for one, actively decided to censor the transaction, it would still make its way into a block eventually.
What if I decided that a transaction was so heinous, so unbelievably evil, that not only would I not mine it, but I wouldn't mine on top of it either? Unless I hung up my ASICs for good, I would have to ignore any blocks containing the transaction and attempt to build a bigger chain on top of the previous block.
I'd need to produce 2 blocks before another miner produced the next block. If I wasn't successful I'd have to produce 3 blocks before another miner produced the next block. The task becomes exponentially more hopeless as each block is mined.
The only way I could be successful is if I either controlled 51% of the hash rate or convinced 51% of the hash rate to join me. Even in the unlikely event that other miners were ideologically inclined to censor, they would only join in if they believed 51%+ of the hash rate were following the same regime.
And thus this is how bitcoin has successfully resisted censorship ever since that fateful January afternoon in 2009 when a kindly soul, with butterflies in their heart and The Times of London in their hand, published the genesis block.
Bitcoin is beautiful!