I think you're correct. It does alter the distribution for each output token, implicitly giving each candidate token a different probability. Maybe that's fine, but it's not as magical as Anthropic [and a lot of commenters here] are making it out to be.
Finally convinced myself that non-distorting watermarking is real, a la Anthropic / Google SynthID. It's not just spin / marketing. This really is a "Monty Hall" like problem. (h/t @random_walker for that analogy.)
Sharing here in case it helps anyone else.
On one hand, watermarking is "obviously" damaging to the output. The LLM does all this work to compute token probabilities... then you essentially perturb the probabilities? Of course that's bad! Every single token is using perturbed probabilities!
On the other hand, you obviously can freely inject a layer of randomness into sampling. Take any categorical distribution. For each sample, perturb the probabilities, then draw the sample. Done correctly, over many samples the results will match the original distribution.
It still kinda feels like magic, but it's not surprising that you can take that core trick and shape it into a non-distortionary watermarking scheme.
(i.e. it gives you sequences that were just as likely to be generated by the original model as any other sequence)
Thanks for pointing this out. I'm not hating on Cockpit, but Outer Loop (with Outer Shell) has solved a lot more of the stack. Cockpit accepts the constraints of living in existing browsers, so it requires exposing a port to the internet or using some SSH port forwarding tool. Whereas I built a dedicated browser to push capabilities so that users can get a "Just point me to a server" flow.
This thread has been useful -- I think Cockpit will also work great in Outer Loop. And it will be easy to add it as an app in Outer Shell.
> it requires exposing a port to the internet or using some SSH port forwarding tool
This sentence is bizarre to me. Your SSH-based solution also requires exposing a port to the internet and installing a special tool (on both server and client!). What's so special about SSH that using HTTPS is a problem but using SSH isn't?
The industry also tried the whole "use the web browser to run native binaries" thing with ActiveX (and the unity web player I guess). The idea was thrown out along with flash and java applets for what I presume were security and portability reasons.
If you can SSH to a machine, you can use Outer Loop and Outer Shell, without having to do any sudo commands or expose anything new to the network. The browser + SSH client combined into a single app leads to nice user experiences like this. The final section of the post was saying that it's strange such a thing doesn't exist already.
> without having to do any sudo commands or expose anything new to the network.
Again I'm not understanding the distinction. I don't need to run sudo commands to install a web server, and depending on your definition of "exposing something new" to the network then either I don't have to do that either or your solution also does that.
Something is getting downloaded and run on the remote machine, correct? Why is it problematic for that something to be a web server (with SSH-forwarding I guess) instead of this custom thing?
And why install anything on the server at all if it'll just serve a binary that downloads and runs on your local computer anyway? For example, if I type `sftp://username@server.domain/file/path` into my file manager's address bar, I get the nice file browsing experience you demonstrate without installing anything on my computer or the server.
EDIT: OK, after reading through your earlier posts, I think the value proposition really is just that you've implemented a slightly better UX for proxying remote web servers via ssh, and that the "run native code" thing is an independent idea you are also pursuing. So the answer to the question "isn't this just proxying an http server over ssh" is basically yes.
I think I incorrectly read this as attempting to propose a radically new idea and not as an incremental improvement to the status quo.
> it requires exposing a port to the internet or using some SSH port forwarding tool
I think what they meant is that the SSH server can be behind your webserver and not have to have its own public IP exposed directly... but of course there are an abundance of proxy-related solutions already.
Cockpit has a "remote" host connection feature solving this exact pain-point - "Just point me to a server":
You install the Cockpit web service on one host (along with its backend and extensions), and on other hosts you may have - install only the backend of the stack (4-7 packages available via deb backports & other dist repos). The web front host is then able to access any other machine via ssh (if keys and policies permit that) and display info or manage that host. All ports aside from the web front and ssh between your hosts remain as is. It is a decentralized design.
Alan Kay once strongly critiqued web browsers. He argued for a much simpler architecture.
Your experiment somehow reminds me of the better approach that he was hinting at. I.e. I think he would appreciate your experiment as well as the neuroscience in your background.
- sockets are blocked by default, until they are added to an allow-list explicitly on the server side
- True sudo awareness ensures root sockets aren't reachable without the sudo password. (This capability is important, because otherwise you create an incentive for people to run root backends with user-accessible sockets.)
It's a fun heretical idea, moving away from a "cross-platform" web to a "multi-platform" web. It's a cross-platform protocol that hands off to platform-specific frontend code. I think it's a natural direction for the web, in a world where LLMs can translate to other platforms.
I think there are different clusters of people who use servers, SSH, etc.
I'm closer to the cluster that uses them for deep learning experiments, GPU kernel optimization, robot development (a robot is just a server that moves!)... use cases where you are explicitly using a remote computer.
For this cluster of people, I think this tool feels more intuitive than the flow you suggest. But maybe I'm projecting!
And, to me, this just feels like one of the fundamental things that could exist; it's like a graphical operating system, but remote-first.
In all cases, the code is pre-compiled. A user never waits for anything to compile. When Outer Loop installs Outer Shell, it downloads pre-compiled binaries to the server. For Linux these are compiled against a manylinux ABI. Ditto for when Outer Shell installs one of the bundled apps. When a backend serves a native "web" app over HTTP it sends already-compiled ARM (or x86) code to the client.
Dependencies are less of a concern for the frontend binaries. For backends, I use a dependency-light approach, static-linking anything that's needed. Of course, people are welcome to do backends however they want, and just tell Outer Shell about the systemd/launchd units via the API. I used this no-dependency approach to keep everything lightweight and to keep install steps trivial, but admittedly it pushes me in certain directions (for example, using custom binary formats rather than sqlite).
On various Mozilla forums that I saw, the discussion was basically:
1. We can't just allow the browser to connect to any socket, since many either explicitly don't want browsers connecting to them, or are oblivious to browsers.
2. ...so we need to also add some sort of allow list
3. ...this is getting too complicated for such a niche feature.
So I think the nicheness was the high-order bit here.
JavaScript and wasm should not be able to open generalized networks sockets because no one wants an asshole to be able to buy an ad on a shitty ad network and send malicious code to people’s browsers which attacks all the internal devices on the user’s network simply because the user wanted to read a movie review.
