Post #327291
2026-02-17 22:16 UTC
Replies (17)
-
@nasser@merveilles.town 2026-02-18 11:57
conversations around this have been super generative, thank you everyone for your feedback 🙏 I think a compromise position that serves people who want to make their own non-browser frontends but preserves the underlying semantics this thing needs without requiring people to get automerge to work in their environments could be: expose the automerge update API over http. so the endpoint I would use in JavaScript would look like PUT /issue/:id where bytes is the automerge blob that comes out of automerge.save, everything managed in the browser. but I'm suggesting exposing another endpoint like POST /issue/:id.json "[{type: put_object, ...}], [{type: splice_text. ...}], ... (HTTP verbs and paths speculative of course) where you can upload a sequence of automerge document mutation operations. I feel like that could let non-browser users participate fully without burdening them with extra integration work if they don't want to do that.
-
@technomancy@hey.hagelb.org 2026-02-17 22:19
@nasser I have grudgingly switched my default ubo mode into only blocking 3rd-party scripts instead of blocking scripts so this wouldn't be a deal-killer for me but if I'm being honest I'd probably just write an emacs mode for its API instead anyway and skip the web interface if I used it seriously
-
@danialbehzadi@persadon.com 2026-02-17 22:36
@nasser Does it work with git send-email?
-
@skyfaller@jawns.club 2026-02-17 23:08
@nasser I'm most concerned about total energy use / emissions on client + server. I despise JavaScript because of the bloated interfaces using it that make my fans spin up. Would one of these implementations be more efficient overall? I also find JavaScript aesthetically displeasing as a language and I don't like adding to Brendan Eich's legacy, but LLMs seem like a much larger threat to the environment these days and they might be even harder to avoid than JavaScript now. No LLMs here right?
-
@KekunPlazas@mamot.fr 2026-02-17 23:40
@nasser Frankly whatever as long as the data is well defined so other clients can exist.
-
@trurl@mastodon.sdf.org 2026-02-18 03:42
@nasser it sounds like the data layer is directly addressable in a way that would support multiple UIs. Is that your intention? If it's straightforward to build a non-browser-based interface (CLI, Emacs, ...), then JS in the browser UI seems okay. But if HTTP+HTML is the only supported UI, I'd prefer a JS-free interface I can use from Emacs (w3m-el) or the terminal (w3m, lynx, ...).
-
@addison@nothing-ever.works 2026-02-18 04:10
@nasser@merveilles.town What is the data model on this? How are issues and such stored, presumably in the actual repository somewhere?
-
@afranke@mamot.fr 2026-02-18 07:35
@nasser you may be interested in https://github.com/git-bug/git-bug
-
@ropoko@mastodon.gamedev.place 2026-02-18 12:53
@nasser is this going issues/tasks going to be synced with the issues on github/gitlab? fun fact: I had the same idea last month and was preparing to start building something like this
-
@ajn142@infosec.exchange 2026-02-18 13:08
@nasser @whitequark JMHO, this sounds like it ought to be two separate tools: Extension to Git to incorporate the optional use of PRs and issues on a text-first basis, like what the rest of git does for source code.Local webserver interface that supports doing all the things like you would in GitHub or other tooling, including issues and PRs.
-
@lxo@snac.lx.oliva.nom.br 2026-02-18 13:23
if we control the server that sends javascript to our browser, there's no loss of freedom involved, so no objection from me. holding issues and PRs locally sounds great, I look forward to it. I'm curious about the data model that will enable seamless merges as multiple users update issues without coordination.
-
@jaseg@chaos.social 2026-02-18 14:54
@nasser Your project sounds really cool! I’d love to see something like this exist in the world. Personally, I think having a modern-feeling UI that uses JS in places where it makes sense would be important to make this accessible to more people. I think some important UI features like search suggestions, link (e.g. issue) previews on hover, and smart dark mode handling are just not possible to implement (well) without JS.
-
@musicmatze@social.linux.pizza 2026-02-18 15:07
@nasser don't want to crush your enthusiasm, but do you know of radicle? https://radicle.xyz
-
@drayde@fosstodon.org 2026-02-18 15:35
@nasser yes, in case there's also a cmd line interface or API
-
@ari@chaos.social 2026-02-18 15:51
so does this git subcommand somehow comes with a particular repo I'd like to contribute to, or would it be something from my software distribution (linux distro / f-droid / ...)? Running software "directly" on my computer is a way bigger deal then running some JS in firefox - I'd rather not do that either but as long as I wont to participate in the internet I guess I have to. If it's from my distribution, I don't mind it running JS (or anything really) in my browser. @nasser
-
@raphaelp@types.pl 2026-02-18 17:00
@nasser voted yes with the goes-without-saying assumption that it doesn't load additional javascript from the internet, only uses local code
-
@sellout@mastodon.social 2026-02-22 20:14
@nasser Not to push feature requests on you, but wondering if this supports different issues per branch (like https://github.com/kalkin/be/ does) or not (I _think_ git-bug doesn’t, right?) I’m guessing the git object approach precludes it, but I‘m no expert.