DanConwayDev

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

Public Key

npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

NIP-05 Address

dan@gitworkshop.dev

NIP-57 Address

danconwaydev@minibits.cash

Profile Code

nprofile1qqs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqgdwaehxw309ahx7uewd3hkc0m2yzq

Publishing to

relay.nostr.band

nos.lol

relay.damus.io

Author Public Key

npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

Show more details

Last Notes

2024-09-16 19:08:47

- reply

Three options:
1. No merge - squash the commits in the branch, rebase onto master, set the tip of master to that commit. History is lost.
2. Merge - don't squash. Merge into master. The CI should just run on the merge commit. This will keep the useful history for future reference for everyone.
3. Add directly onto master - rebase on master, reset master tip to the tip of your develop branch.
If you go for option one you could keep a local branch that hasn't been squashed for your own person reference.

2024-09-11 08:49:52

- 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-10 11:58:20

- reply

Who is we?

2024-09-06 13:35:20

- reply

This is the challenge. Clients aren't incentivesd to support it because most clients don't publish with it. Clients don't publish with it because most clients don't support it. Catch 22.

2024-09-06 13:26:59

- reply

Is that the generic reply kind? Why clients support notifications for that?

2024-09-06 13:05:12

- reply

This is an example of progress. We just need a few more @nprofile…69jx's out there nudging people towards creating issues on nostr and adoption will increase and then hopefully snowball. Thanks @nprofile…69jx
#nevent1q…8fvc

2024-09-05 06:08:45

- reply

The incentive were a little higher!

2024-09-04 12:02:13

- reply

*winning

2024-09-04 11:09:40

- reply

I was referring to NIP-34

2024-09-03 10:28:12

- reply

If they are already on nostr in don't think it is rude.

2024-09-03 09:38:17

- reply

I agree. we need more analysts/designers/testers/sysadmins. Our ecosystem would be stronger if there was more kudos of those contributions.

2024-09-03 09:19:10

- reply

Interesting idea. I wonder why the other projects didn't go down that route. I wonder if contending with the in browser approach to a file system was the source of the issues.

2024-09-03 08:47:50

- reply

The content of each commit in a PR is sent via nostr relays. The commits from maintainers pushed to the `main` branch are just sent to the git servers listed in the announcement event. However, is really easy for maintainers to change the git servers that everyone pulls from. NIP-34 turns git servers into dumb data relays similar to nostr relays.

2024-09-03 06:52:19

- reply

Maybe, the user could choose to use the browser, use their locally cloned repos via a new command like `ngit serve`, or use a service that does it in the cloud and serves them the required data at much lower bandwidth.
#nevent1q…erg4

2024-09-03 06:37:23

- reply

We discussed it back in March and here are some numbers for the bitcoin core repo:
#nevent1q…gmr6
tbh those numbers are not that big. last time I checked, git implementations in the browser don't support these advanced flags. doing a full clone automatically in the browser is probably a bad idea as it is unfair on those who are bandwidth constrained.
But this could be done statelessly on a server fairly quickly. bandwidth on a VPS is probably quite cheap these days so if traffic volumes were low it shouldn't be too expensive.
Depending on the bandwidth vs storage costs it could be worth storing a clone of repositories and using that instead. That way it would be easier, or cheaper per interaction, to allow browsing commits, metadata, etc.
From a decentralisation point of view, I could build `ngit serve` which could be used instead (even in offline scenarios) instead of the proxy.

2024-09-02 20:05:19

- reply

as you can see the HTTP API thing is a bit of a mess but the most common format is`https://<host>/<path/to/repo>/raw/<ref>/<path/to/file>`
```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}`
)
}),
]
}
```

2024-09-02 19:43:07

- reply

There is a CORS error. Either I need to turn the proxy back on or your site needs to accept CORS requests for at least https://git.sprovoost.nl/sjors/instablossom/raw/branch/master/README.md
I need to find a recommended hosting provider that doesn't require KYC and accepts bitcoin first, as I'm running up against the monthly function invocations allowance for my current provider on the free tier.

2024-09-02 18:47:49

- reply

I considered that and experimented with it. There is a lack of support to do it in the browser. In any case, it is too heavy to do client side. And too slow / bandwidth inefficient to do on demand on the server-side. It could potentially be done as a job run daily but it is ultimately reliatively expensive operation to run give we are just looking for the readme.

2024-09-02 15:06:05

- reply

unfortunately the git feature for getting the contents of specific files `git archive` is off by default so it makes getting the README.md challenging.
many git server implementations expose raw files in a repo over https using similar APIs. Unfortunately some of them don't allow display directly CORS and other eg github have heavy throttling.
until last week I was proxying requests to allow support for git servers without CORs exceptions but I have, perhaps temporarily turned that off so gitworkshop.dev could be entirely statically built.
when I wrote the feature it supported (with the proxy):
self-hosted: gitea, forgejo and gitlab
hosted: github, bitbucket.org, gitlab.org, gitea.com, codeberg.org, sourcehut, launchpad.net
feedback welcome on how to proceed with this.
I'm thinking about opening a PR for @npub180c…h6w6's song to expose the raw files over https. would you be interested in this @npub180c…h6w6?

2024-09-02 10:50:06

I'd like to add gitworkshop and ngit to nostrapps.com but they currently don't have logos. Can the #nostrdesign community help? #asknostr

2024-09-02 09:10:47

- reply

re run `ngit init` to modify and issue the repo announcement event. allow creation and modification of this in gitworkshop.dev is coming soon.

2024-08-31 08:33:46

- reply

You should be in on

2024-08-30 20:08:14

- reply

Thanks. We will stick with that for now then.

2024-08-30 20:07:40

- reply

Yes, spelling error. But the new proposed format is shorter. I'm concerned about implementing loads of ways of doing it and forcing anyone else who wants to use the cloning syntax to do the same.

2024-08-30 19:54:19

- reply

I moved it and tried a few other things but not 100% happy. Maybe I should pull the instructions out of the down to makenitnmore prominent?

2024-08-30 19:06:35

- reply

yes, it might be able to find the event but its better to include a relay hint.

2024-08-30 19:04:40

- reply

I could use one of the other coloured buttons. If I remember correctly its the most prominent thing on the github repo page. A big green button called 'Code'.

2024-08-30 18:54:54

- reply

advertising has trained us to ignore bright shiny things on websites.
I'm open to suggestion on how to make it clearer. the 'new issue' and clone buttons are perhaps too similar.

2024-08-30 18:53:02

- reply

FYI @npub19w6…syzj @npub1yay…trdv @npub1ecd…s735 @npub1q6y…t3sh

2024-08-30 18:48:55

- reply

There will be a call to discuss next steps on creating DVMs for CI on Tuesday 1500-1600 UTC. All welcome. This one will be on Signal. https://signal.group/#CjQKIKJiex5Jw2qDiV9QjJ7zVSGoNG5kCH9XUhdq4r4QVYsuEhDFFZuW9SDMgC7N3QDpL4QF

2024-08-30 18:45:29

- reply

you can rename it or name it as part of the clone command `git clone nostr://npub123/my-repo my-repo-directory
if you think it should default to the identifier please comment here:
#nevent1q…wjna
Do you think its worth changing? I think its only ngit that currently uses it so no other client will need to change.

2024-08-30 18:28:47

- reply

this is failing because the nostr url points to @npub1m4n…c2jl who doesn't have a git repository with the identifier Alexandria. try @npub1l5s…gx9z
a good way of finding the right nostr url to use is to view https://gitworkshop.dev/repos as you can select a repo and copy the clone url via the green 'clone' button

2024-08-30 18:24:00

- reply

correct

2024-08-30 18:14:51

- reply

Git calls the remote helper with that environment variable set along with a few others.

2024-08-30 17:43:37

- reply

Your still getting the 'no repo event at specified coordinates' error?
And you definitely installed to upgraded remote helper too?

2024-08-30 16:08:59

- reply

I included a fix in v1.4.5 @npub1hw6…65gr
please can you try it out to see if you still get prompted for authentication when pushing a new branch?

2024-08-30 16:06:02

- reply

brilliant! did you use `ngit send` or `git push -u` on a branch prefixed with `pr/`?

2024-08-30 14:03:16

- reply

This came up a few days ago. I know you love for nip discussion on github is strong so I'll post a link to the discussion:
https://github.com/nostr-protocol/nips/pull/1446
I hope to get to this soon

2024-08-30 13:45:02

- reply

also reported here: #nevent1q…ute7

2024-08-30 13:44:37

- reply

I'm closing this as a duplicate of #nevent1q…flla

2024-08-30 13:40:53

- reply

v1.4.5 should fix this under bash

2024-08-30 13:37:49

- reply

I pushed v1.4.5 did that fix this?

2024-08-30 11:50:49

- reply

There is a project called nostrCI that @npub1zaf…26k5
presented on in riga. its about interoperability across nostr clients and there is a overlap with CI on nostr. There is a signal group for it and a call happening at 1430 UTC. If you want to join the singal group or the call, please shout up.
@npub1mgv…pdjc @npub19w6…syzj @npub1myg…sn5p @npub1ecd…s735

2024-08-30 11:43:31

- reply

@npub1myg…sn5p is interested in this too

2024-08-30 09:44:13

- reply

@npub15qy…yejr discovered this and it should be fix in commit b4459e98d816f6f278a4e9ab76883008d0b946fe which forms part of the next point release.

2024-08-30 08:11:12

- reply

the getting started guides on gitworkshop.dev are sufficient at this stage. If anyone is struggling. feel free to repoen this issue

2024-08-30 07:38:23

- reply

sure. I just pushed an update for this. it would be nice if NDK's `event.encode()` does this automatically @npub1l2v…ajft . it is just a one line change.

2024-08-30 07:04:48

- reply

Appreciate you guys

2024-08-29 12:22:38

- reply

I think this is related to an issue with rust-nostr v0.33 as I had this with one other repo. I have bumped this to v0.34 on the master branch which fixed it for that repo so that might fix it. I'm away from my desk until tomorrow but I'll issue a minor version of ngit with the fix tomorrow.

2024-08-28 21:38:46

- reply

Thanks. I'm now using it.

2024-08-28 19:11:08

- reply

yes that works with the previous 500ms timeout.

2024-08-28 18:13:06

- reply

Just one:
```rust
fn get_first_proposal_event_id() -> Result<nostr::EventId> {
// get proposal id of first
let client = Client::default();
Handle::current().block_on(client.add_relay("ws://localhost:8055"))?;
Handle::current().block_on(client.connect_relay("ws://localhost:8055"))?;
let proposals = Handle::current().block_on(client.get_events_of(
vec![
nostr::Filter::default()
.kind(nostr::Kind::GitPatch)
.custom_tag(
nostr::SingleLetterTag::lowercase(nostr::Alphabet::T),
vec!["root"],
),
],
nostr_sdk::EventSource::relays(Some(Duration::from_millis(1000))),
))?;
Handle::current().block_on(client.disconnect())?;
let proposal_1_id = proposals
.iter()
.find(|e| {
e.tags
.iter()
.any(|t| t.as_vec()[1].eq(&FEATURE_BRANCH_NAME_1))
})
.unwrap()
.id;
Ok(proposal_1_id)
}
```

2024-08-28 18:10:16

- reply

It gets triggered in ngit intergration test module list::when_latest_revision_rebases_branch
So those tests endlessly run with a timeout of 500ms under v0.34.0 so I bumped it to 1000ms.

2024-08-28 17:57:11

- reply

Relay

2024-08-28 16:18:44

- reply

I've released there is a problem with the format. if you dont specify a directory name, git will use anything after the last `/`. so in this case it will add the ?relayhint=git.fiatjaf.com to the director name.
perhaps we should switch to the less intuative but still readable:
nostr:://npub123/git.fiatjaf.com/relay.damus.io/identifier

2024-08-28 16:14:29

- reply

is it a problem if you can use either?

2024-08-28 16:04:43

- reply

This is great. I'll get ngit working with it.

2024-08-28 15:49:25

- reply

are you referring to the "client overwrites my list with empty values" problem?

2024-08-28 15:25:33

- reply

They miss notifications that amethyst captures

2024-08-28 15:25:04

- reply

*reads raw json to see if anything interesting is happening*

2024-08-28 15:22:43

- reply

You know how people in bitcoin talk about month long detailed discussions about new approaches to something and then up realising that greg maxwell suggested a better approach 10 years ago? I feel that way about fiatjaf sometimes.

2024-08-28 15:17:43

- reply

Good point. and blossom. I would actually prefer this to reduce the number of events we need to ask for and manage but I'm pretty sure you meant this as a counter argument.

2024-08-28 15:01:22

- reply

You can zap commits submitted using NIP-34. For example:
#nevent1q…swn2

2024-08-28 14:57:46

- reply

I need to add zapping support so we can don't directly in gitworkshop.

2024-08-28 14:57:00

- reply

I just zapped this commit using amethyst:
#nevent1q…uleu

2024-08-28 14:23:27

- reply

Is this a terrible idea?
```
{
"kind": 10002,
"tags": [
["r", "wss://expensive-relay.example2.com", "write"],
["r", "wss://git.fiatjaf.com", "git"]
],
}
```

2024-08-28 14:13:51

- reply

I'm also in that club. It's so satisfying seeing your creation work seamlessly under the predefined test condition before it gets broken by the real world.

2024-08-28 14:11:41

- reply

yes, its great to have more options to access AI without KYC.

2024-08-28 12:48:11

- reply

yes that worked. but aren't we trusting that the author of the derivation is not including a malicious hash? this is what trustix was trying to solve or an I still missing something?

2024-08-28 12:40:37

- reply

Simplistically, if someone starts posting git events but then stops, then they havn't been retained.

2024-08-28 12:15:17

- reply

As a creator of tools which I hope will bring value to those who use them, user retention is a useful measure of whether user received value enough to return.

2024-08-28 10:48:03

- reply

What do you mean by that stuff?
I'm a big privacy advocate and hate the heavily surveillance of user activity which is used to dominate and control us. but we can use their learning to improve user retention and provide better experiences.

2024-08-28 10:41:11

- reply

apparently it is not a valid store path

2024-08-28 10:31:13

- reply

completely agree

2024-08-28 10:30:12

- reply

I get that the incentives are skewed. but they are pretty effective at attracting and retaining large number of users. to achieve this they do heavily surveillance on user activity, many iterations of a+b testing tweaks to their UI to create UX. If we can learn lessons from them, so long as we critically evaluate knowing they are prioritise attention and retention above satisfaction and well being.

2024-08-28 10:23:39

- reply

in the first example they use I'm guessing cigxbmvy6dzix98dxxh9b6shg7ar5bvs is the derivation hash and qhqk4n8ci095g3sdp93x7rgwyh9rdvgk is the output (binary) hash. Is that right?
In which case the derivation doesn't include the output hash or am I missing something?
https://nix.dev/manual/nix/2.18/command-ref/nix-instantiate#examples
```
nix-instantiate test.nix (instantiate)
/nix/store/cigxbmvy6dzix98dxxh9b6shg7ar5bvs-perl-BerkeleyDB-0.26.drv
nix-store --realise $(nix-instantiate test.nix) (build)
...
/nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26 (output path)
ls -l /nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26
```

2024-08-28 10:09:22

- reply

so `nix-instantiate` gives the hash of the derivation and `nix-store --realise` produces the hash of the actual binary output?

2024-08-28 10:01:06

- reply

100%

2024-08-28 09:27:59

- reply

5 star rating systems are used by data driven tech companies which have huge resources to study their effectiveness, such as Amazon. The fact that they haven't moved away from it is signal that its useful.

2024-08-28 09:01:57

- reply

but how do you get the derivation output hash from the build recipe?
thats a cool project. thats exactly what I was talking about with different peers doing the build and reporting back that they got the same hash. These could be nostr trust attestation events.

2024-08-28 08:51:15

- reply

I had to look that one up!

2024-08-28 08:48:28

- reply

haha. who ever uses 3 stars? its 1, 4 or 5.

2024-08-28 08:47:49

- reply

😂 step 1. log into my app, step 2. automatically sends 5 star review with glowing comments without you realising.

2024-08-28 08:44:55

- reply

as we live in a bazaar, you can control how other clients might 'abuse' a carefully thought rating system. for example someone may have designed a 1-5 rating system for an event kind and use it extensively in their app. Another client presents the user with the option to star the same event and sends in a 5 star rating.

2024-08-28 08:40:18

- reply

Yeah, it is pretty cool

2024-08-28 08:38:13

- reply

I know right. its the magic of nostr. it is why we keep showing up.

2024-08-28 08:36:54

- reply

yes

2024-08-28 08:36:27

- reply

but numeric rating systems are only so useful.
evaluating other heuristics can lead to more accurate summary of the opinion of your community.

2024-08-28 08:32:07

- reply

but if you don't build yourself, you are trusting whoever has given you the hash. getting trust assertions from a verity of sources that a version should produce that hash means that you are drastically reducing your trust in any one source.

2024-08-28 08:27:47

- reply

it wouldn't take much computing power to produce those events, but relays might reject them as SPAM if they have old timestamps.
Hopefully we could do an ok job at identifying the spam, between relays, WoT analysis and even more sophisticated WoT analysis done by DVMs. Thinking more about it relays are pretty incentivised to do good spam prevention. we could select relays we think are doing a good job at it and use them rather than using DVMs too much.

2024-08-28 08:22:18

- reply

a repo might have an iOS, Android and Web application profile, and the opinions of those profiles should be somewhat separate because the UX might vary significantly.
I think opinions are more likely to be made against the application profile than specific releases. I'm unsure of the best way to gather opinion heuristics in this area and how to display them to the user.

2024-08-28 08:16:52

- reply

As of yesterday they are now in zapstore. I plan to display all releases related to a git repository in gitworkshop.dev

2024-08-28 08:12:53

- reply

In Riga we were discussing having a
1) a generalized DVM that finds events that indicate an opinion on the thing (product, app, etc) and filters out the SPAM; that feeds into
2) DVM specific to a usecase that takes that opinion data and summarise it in a whay that is useful to a client. eg so they can prioritise its display in the interface or express the opinion through words, emojis or, god forbid, a 1-5 star rating.

2024-08-28 08:03:34

- reply

If there were a two way relationship between the 'application profile' in the app store NIP and the 'repository announcement' in nip34, then clients could associate those ratings with both things. currently it is one way (nip34 announcement is referenced by the application profile event).

2024-08-28 07:59:21

- reply

I often build binaries from source. Wouldn't it be cool if, whenever I built a binary from a reproducible build, I could elect to easily publish to say that I validated that the commid-id / version tag produced a binary with the correct check sum, or not via nostr?

2024-08-28 07:55:22

- reply

As a nix user, and as a maintainer of a project that needs binaries installed, I'm also more broadly interested in your idea. This is on top of the obvious overlap of A DVM that builds binaries.

2024-08-28 07:52:44

- reply

Definitely. @npub1wf4…dgh9 and I both have immediate usecases for a DVM that runs CI to build artifacts (for @npub10r8…t2p8) and lint, tests etc (for #GitViaNostr). We were thinking that may projects have github actions and there is an open source GitLab CI runner that github actions so that could be a good place to start.
Then we met @npub1hw6…65gr who was also interested in this and @npub1grx…87js who is interested in DVM more generally.
Now you are up to speed on the context!

2024-08-28 07:42:24

- reply

but also I have friends who I have little overlap in movie or restaurant preferences. The fact that they liked something actually signals to me that I wouldn't like it.

2024-08-28 07:41:30

- reply

@npub1wf4…dgh9 is a 1-5 star rating system maxi

2024-08-28 07:37:34

- reply

You could also value to the rating of npubs that like the same things you like more.