holtwick

The briefing pages also have RSS, this way you see the most relevant stuff https://bubbles.town/editions

I love it!

Small web, try this one https://bubbles.town

There's nothing bad about SFU, particularly the version you wrote, which forms the basis of Livekit. It would be my first choice for supporting larger groups in Briefing anyway. If the traffic is E2EE, it doesn't matter if an SFU is involved. The critical part is the signalling, in my opinion. This is where the initial communication is established. In the current version of my app, whose source code is yet to be published, this can happen via an untrusted server.

For small groups SFU like Livekit is not needed at all. Still E2E and realtime collab. I wrote such a thing: https://brie.fi/ng

Inspired by this tool I wrote something that fits macOS better. It uses the native sandbox-exec from Apple and can wrap other apps as well, like VSCode in which you usually run AI stuff. https://github.com/holtwick/bx-mac

FluidVoice for macOS is pretty handy as well. Open source under Apache License. https://altic.dev/fluid https://github.com/altic-dev/FluidVoice

I'm keeping my fingers crossed! Hopefully it won't just remain at the announcement stage.

I wonder there is not already such a petition in the EU or Germany. I searched, but didn't find any. Somebody who wants to create one? I'm not that good in writing such texts:

Europe: https://www.europarl.europa.eu/petitions/de/home

Germany: https://epetitionen.bundestag.de/epet/startseite.nc.html

Thanks for sharing, this is super interesting. Although it doesn't seem to be super active these days. Probably because it is difficult to commercialize local first. That might be why we need a widely adopted and super flexible standard to become attractive to hosters of such services.

I would like to refine my answer regarding the rapidly growing log. If we assume that we have a real-time application, then every keystroke or pointer action can indeed create a change entry.

But this storage format is designed for "long term" and "slow" operations. Where "slow" means in the time lapse of a second instead of a milisecond. This allows us to combine multiple changes into a single log entry.

CRDT implementations like Yjs are good at concentrating such changes into smaller chunks of data. For example, writing text in a rich text editor like Prosemirror is then reduced to something like a string and a position.

But the UI can also be lazy and throttle things. A string input field can only fire changes when the field is left or not typed for a second or so.

These steps will significantly reduce the size of the log. They did in my implementations.

But this is not the end of realtime for such applications. These applications could still pass changes directly over P2P, as long as the log remains consistent, so that the resulting document will always eventually consistent.

Thanks for feedback. The link is broken for me, but I think you are referring to this page? https://jack-vanlightly.com/analyses/2024/4/29/understanding...

Indeed, the approach is similar. Especially the separation of assets (they call it "Data files") from the log ("Data log") is something I consider being a good choice.

For certain scenarios there will be conflicts, take a boolean value. Client A sets it and client B unsets it. There can only be one winner.

But that might be a benefit from the proposed log sync, because these conflicting situations can be shown and marked for human review in the UI. Each step of change is well documented and the history can fully be reviewed.

Thanks for the detailed feedback.

The growth of the log is indeed a weak point that could be improved by regularly merging entries. Missing entries are easily recognizable because a consecutive index is used. The checksums on the previous entry should improve data consistency.

The point that CRDTs themselves already contain all the information required for an update is absolutely correct. I have been working on this protocol for some time and one objective was the reproducibility of the individual changes fro accountability reasons. But this may not be necessary for all applications and could possibly be achieved in other ways. Thank you for pointing this out, I will reconsider the concept in this respect!

Receipts - for macOS, local database, automated content recognition, document management. Convenient commercial alternative to GnuCash to track expenses and income. https://www.receipts-app.com/

https://onepile.app/

CSS/Stylus framework inspired by Tailwind, trying to respect the content semantics https://github.com/holtwick/windy-css

I'm not a lawyer, just a coder. I was under the impression, that offering a network service is also defined as 'distribution': https://choosealicense.com/licenses/eupl-1.2/

I guess under (1) the "providing access to its essential functionalities" part is relevant: "‘Distribution’ or ‘Communication’: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person."

Why not EUPL? It is probably a good choice for a European based company and has comparable features. https://github.com/holtwick/briefing/issues/75

I can fully understand that an additional tool layer can cause additional problems, but static type checking is a large quality win for large projects. There are workarounds to achieve similar results:

(1) Use a faster bundler like esbuild, here vite's similar considerations [1]

(2) Use Flow [2] and just strip it away before distribution like this Babel module [3]

---

[1] https://github.com/vitejs/vite#typescript

[2] https://flow.org/

[3] https://babeljs.io/docs/en/babel-plugin-transform-flow-strip...