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 #include int main(int c,char**v){int i,j;for(i=1;iatoi(v[j+1])){char*t=v[j];v[j]=v[j+1];v[j+1]=t;}for(i=1;i

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.

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.

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?

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.

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.

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

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.

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.

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.

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?

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.

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.