Last Notes
Yes your right. The output of those different phases should be consolidated so you just see the status per relay / git / grasp server.
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
I thought about doing this to make @nprofile…cd2e's favourite and @nprofile…xuyp 's least favourite client at the same time
Fantastic to see this coming together
#nevent1q…lgfa
So your needs are: 1) basic Issue / PR flow with good review tooling 2) moderation tools 3) CI tooling? Have I missed anything?
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.
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.
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.
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."
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.
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.
How's the gnostr stuff going?
In my proposal there are multiple packs relating to groups of commits in the history so the hashes don't change. Uding ^2 exponential.
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?
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.
@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.
I'm not seeing that comment.
This is because a git repository can't be found at the git.gitter.space address listed in the announcement. @nprofile…cy97?
Let every client be a git nostr client
#nevent1q…s9j2
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.
ask and you shall receive
#nevent1q…ryvq
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.
Some features, such as card payment authorisation, aren't available through the web.
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.
I needed to hear that. Thanks.
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.
@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.
Yes, I'll add it with a left-pad protection scheme.
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.
No not yet. https://gitworkshop.dev/notifications is a good place to see notifications for #gitvianostr
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?
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':' ');}`
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
I made it a PWA a month or so ago, clearly not as successfully as I thought.
So you're getting this too?
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.
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?
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.
@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.
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.
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
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
@nprofile…evew the rust developer
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.
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.
I'm sure the midcurve meme apply here with 'just let git handle that'.
The reference implementation does exactly that. It uses nginx to pass request to the git-http-backend CGI scripts maintained by the git project.
Nice! Would love to see it.
