Last Notes
I did. Yet I'm not sure where it will go yet.
https://image.nostr.build/76910fd04c27d85d6b7d5b971cf52029b22ed9d1ed8f29010d862e9a38b034ff.jpg
It's mostly about the synergy of signers + DMs mess, which I believe is as close to resolution as ever.
There's definitely a tension in the beginning: NIP-17 reliability is not just some meme. Clients are either buggy or/and propose wrong relays by default—this destroys UX in the beginning:
#nevent1q…4j5h
Two of my close contacts either ran into exactly this issue or something similar. We don't see these bugs because we know what we do, and we don't normally use such crappy hardware as the cheap Samsung phones (with their custom firmware that always lags from the upstream Android).
The problem with singers: bunker:// URI works great, but it's inconvenient to use for somebody who wants to connect from desktop to Amber. nostrconnect:// supposed to fix it, but it appears that clients propose some other relays the user didn't choose; these could be dead/slow/unavailable relays from their location.
I ended up writing another starter guide/tool due to all this frustration:
https://codonaft.com/nostr-no-bullshit.html
> anything that we could do in order for you to do that
Mostly optimize for reliability:
1. Test apps on the crappiest of the popular devices.
2. Require clients to allow custom relays to be set in nostrconnect://
3. Implement semi-automatic migration of dead relays to new ones everywhere: in ordinary clients and in the signers:
#nevent1q…fjj6
4. Get rid of raw nsec/ncryptsec input lines in the ordinary clients entirely—these are overabused, specifically when something fails with NIP-46.
Every time somebody pastes their nsec in another slopware, I no longer trust them: I don't consider the DMs to be actually private.
#nevent1q…c3kh
Some NIP could already directly state: "nsec SHOULD never be used directly in clients; NIP-46 and NIP-07 SHOULD be used instead". It's like the actual example of why we SHOULD use uppercase SHOULD sometimes—to show how stupid we were by allowing it to do otherwise.
meshstr: a permissionless relay mesh for nostr, published today as an alpha draft.
Relay operators publish, signed, the budget they grant each peer; peers account for their own consumption in signed receipts; a finding against a peer counts only from a node that granted it, and is never imported as a ban. Nothing is implemented yet: this is a proposal, published so it can be argued with, all CC0.
Spec: https://www.meshstr.org/spec.html
NIP on NostrHub: #naddr1qq…4w33
Repository (GRASP-hosted): #naddr1qq…6dws
Reading it and telling us where it is wrong is the contribution that helps most right now.
absolutely amazing
#naddr1qv…nf8y
Interesting that you can see ngit stuff directly in your feed in Amethyst.
#nevent1q…544d
Aqui @nprofile…rca8 o repositório do Armada
#naddr1qq…x7w3
Take a look at #naddr1qq…w05r
Ya I noticed that merging patches closes the pull requests and I loved that feature. I could probably just use the thread in the pull request for notes instead of creating separate issues.
What I like about issues that automatically close with the branch is that I can do multiple slightly unrelated things in that branch without cluttering the conversation in the pull request..
Would be awesome if this is a low hanging fruit..
Here is a draft spec. #nevent1q…pcvv https://gitworkshop.dev/nevent1qvzqqqqx2gpzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uq3vamnwvaz7tmjv4kxz7fwv35hgar09ec82c30qqsr79zwkfckr85cgyec0hz5u3ch20mqfc3l9ahkwe2df9drjkat8tqvdq9wh
If you just want to clone and pull with a grasp repository you can use any of the git servers listed in the annonucement event. I did this draft grasp spec to allow someone to push with a standard git client https://gitworkshop.dev/nevent1qvzqqqqx2gpzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uq3xamnwvaz7tm8d96xummnw3ezucm0d5hsqgrwmpmlfdc8vzjvemlk4z055lccugf3w4tyer4sl4yujt2tva057vlukhdr
I saw your bounties implementation, but I felt it was too tightly-bound to LNURL and gives too much credence to the code creator vs the reviewer, when the biggest costs are in the review. What do you think about ideas in this thread? ie. leaving the payment out of band?
#nevent1q…6xlc
https://gitworkshop.dev/nevent1qvzqqqqx25pzqen829vwvvu0az0a5svwg2st72n69vfj2pxax3lszkscjudkg3psqyfhwumn8ghj7emfw3hx7um5wghxxmmd9uq3camnwvaz7tmwva5hgtnyv9hxxmmwwashjer9wchxxmmd9uqzqllj0fhhwrxwmmnh7v9pg8v6vv4djtjtvza7xhzfty5yhrgh02ex25vz20
Vibe coding our way to feature parity with github 😄
#nevent1q…75dv
Its probably because the client you are using doesnt support showing the git PR kind.
https://gitworkshop.dev/nevent1qy28wumn8ghj7un9d3shjtnwva5hgtnyv4mqqgrwmpmlfdc8vzjvemlk4z055lccugf3w4tyer4sl4yujt2tva057v49nc6t
The nostr link has relay hints: #nevent1q…nc6t
I decided to interpret this as "until you fix the client that produced the note without the reference" for maxium PoW. So here is the GRASP ssh proxy idea: #nevent1q…s6xr
and here is the client fix PR: #nevent1q…mm3d
#nevent1q…uxyz
It's a kind:1618 pull request event, it doesn't work on most clients.
https://gitworkshop.dev/npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/nos.lol/grasp/prs/nevent1qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwdenkjapwv3jhvtcqyphdsal5kurkpfxvalm238620uvwyych24jv36c06jwf949kwh60xevh5ul
@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.
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.
Whats a blossom pack? is it related to the blossom pack idea i outlined in #nevent1q…qr9d
Are you trying to express that issue X and issue Y will be resolved when PR Z is merged?
What are the trade-offs? Not sure if I understand them well enough to make this call..
If you are interested, here are my thoughts about the best way to use blossom for git:
It's inefficient to create one blob of the whole git repo each time a branch tip changes eg. using `git bundle`. This forces users who have already cloned the repo to download the whole thing again to pull just the latest commit. Imo the optimum way of doing it would be to group commits based on powers of 2 and create blobs of each group using `git packs`. I made a start here #nevent1q…qr9d but didn't take it any futher because grasp is a much better idea.
Yep, I was the one that deprecated it. Its done in the master branch.
@nprofile…pt5w Can Amethyst use NIP-22 for git issue / patch replies rather than the deprecated git reply kind`1622`?
Do you want to link it to a patch set (tracked in patches or nostr PR event) or to a branch (tracked in git state)?
Off, then the label is lumped in with any hashtag.
On the other hand, it's indexed. Hmm.
Yes some sort of flag would be really useful here. There are a lot of non malicious reasons to mirror a repository when the only copy is hosted on github.
I think social interactions on gitworkshop could also contribute to a network effect that drags the actual of the repo maintainers onto ngit..
The intent of `git repository announcement` kind `30617` events was to claim ownership of a repository and indicate that you are accepting Issues and PRs via nostr. nip34 reads:
> \[git repositories\] existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general
I expected that announcement would either reflect this or be intentional affinity scams by bad actors which could be weeded out as spam.
I now think the intent is not very intuitive as most repositories on github are private forks for creating PRs or hosted a patch just for that user. Some users created an `announcement` event as they tried to figure out how to do a PR.
Some users wanted to send Patches or Issues to a respository not using #GitViaNostr as a way to encourage them to use it and created an `announcement` event for this.
Trying to enforce a non-intuitive original intention on a permissionless protocol like nostr is like pissing in the wind.
Maybe we should add some flags to the announcement event to enable announcing someone else's repository? Github has the concept of pinned repositories which seems relivant here.
In this case I wanted to mirror it so that I could link to the files on treegaze rather than GitHub - ie. availability. However, if the authors of the code have npubs, perhaps I could even send them issues over nostr
Thanks. I just fixed this in v1.7.1 but now we are hitting this bug that needs to be fixed upstream in libgit2:
#nevent1q…0u4r
The required setting `allow-tip-sha1-in-want` is on by default in many git server implementations but not the one your using.
@nprofile…c33q did some work on this: https://gitworkshop.dev/lez@nostr.hu/git-remote-blossom I also wrote an incomplete PR to ngit to put git packs on blossom to maximise efficiency. Ultimately we both concluded that using a git server is better. Its super efficient, battle tested, has lots of advanced features that people use (LFS, shallow cloning, etc) and allows backwards compatable integration (eg. with CI /CD). #nevent1q…cdp3 https://gitworkshop.dev/nevent1qvzqqqqx2ypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqqsg9w72dve9myu29swk7w9wapqncndnhe98dmfrrd8cjd26fy3lsgsnkqr9d
I've thought some more about this. I think its better for project management style features like kanban to be done in other clients. [gitworkshop.dev](http://gitworkshop.dev) should be able to detect that an issue / PR is referenced by other things (eg tags, boards, epics, etc) and link out to other clients for that.
Seems like a core gitstuff feature.
Or would it be more Kanbanstr? Maybe it should actually be a little task board, like Trello, and I just tie the issues into a card? Almost makes more sense, right?
The`t` tag is designed for this sort of labelling.
We should also be able to apply labels after the issue has been created via nip32. here is the gitworkshop issue for that:
#nevent1q…tw9m
my pleasure t *Y*@npub1mel…5c24
t *Y*@npub15qy…yejr appreciate th@
I've added ngit builds for all OSes versions available from github runners:
ubuntu latest, 24.04, 22.04, 20.02, 24.04-arm, 22.04-arm
MacOS latest, 15, 14, 13
Windows latest, 2022, 2019
see http://gitworkshop.dev/ngit under 'download compiled binaries'
@npub1c03…yrnw was also asking for a delete button so I have one in the menu EventWrapper menu (next to the share and reply buttons under more).
Closing as resolved.
This issue is caused a lack of a distro specific binary. see:
#nevent1q…2xhh
This is implemented in vnext. So much for a quick win! Issues and PRs and events responding to them (status, replies, etch) can be deleted with a tool like delete.nostr.com and gitworkshop will honor the deletion.
If the event is a PR or an Issue and a user has already cached it, it will move into a 'marked as deleted' status. replies, etc will be removed.
If a reply is deleted which has other replies to it, these replies will be shown under the top level thread with a 'missing parent note' heading.
a separate job queue processes each deletion event which trawls through local db entries to remove cached counts of replies and update status accordingly.
cc @npub1elt…cume
@nprofile…crvd
If you want to get zappable issues then this is how it should render
https://github.com/vitorpamplona/amethyst/issues/1279
Not like
#nevent1q…7xpu
Or 5d423bdc57d8d9a39a4179a89adf04475f028c998a9a63f94c7be468be655bf2
[NIP-10](https://github.com/nostr-protocol/nips/blob/master/10.md)
Kind 1 events with e tags are replies to other kind 1 events. Kind 1 replies MUST NOT be used to reply to other kinds, use NIP-22 instead.
I'm glad to hear there is another user out there who manually approves everything 😁
I'm one of those, it helps me to understand the protocol more by seeing more events. Also in this way I catched the `nostr-idb://cache-relay` bug
