onionmx VS manifesto

This readme is quite insightful.

For anyone curious, onion to onion (and even non-onion to onion) works today if the involved SMTP servers know how to handle it. For example, the OnionMX project. https://github.com/ehloonion/onionmx

Great question! onion vhosts ([email protected] addresses) don't need that, as long as your client can resolve onion addresses (Gajim/Conversations have good tor integration, otherwise Tor's AutomapHostsOnResolve will do the trick systemwide but in that case your client may complain that the domain doesn't support TLS or with a wrong certificate).

"Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel.

Another example is if you wish to login as [email protected] by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you the security guarantees of Tor when reaching your server (though not for server-to-server connections).

Onion name discovery for automatically upgrading to onion routing when Tor is available client-side is not yet specified within the XMPP ecosystem. Onion discovery in the HTTP ecosystem is usually done via Onion-Location HTTP header (HTTPS only), in the email ecosystem they use _onion-mx DNS SRV records: see https://gitweb.torproject.org/tor-browser-spec.git/tree/prop... and https://github.com/ehloonion/onionmx/blob/master/SRV.md respectively

Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html

Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list.

All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:[email protected]?join

The toll of feature creep is what led to the informal adoption of The Extensible Web Manifesto, which argues that the web platform should focus on minimalism and performance. New features should be addressed via extensibility whenever possible. Things like WASM, Houdini, and web components were all prioritized to allow implementation of features on top of the platform and thus reduce the rate at which browsers accumulate technical debt. Features being proposed face an uphill battle if they can be implemented using a more generic mechanism, if there are already competitive alternatives, or if the proposed platform extension is not minimal.

The noise floor in the standards process is deafeningly high because there are always some passionate advocates of a technology or feature arguing for its inclusion. A bunch of prominent web platform folks published The Extensible Web Manifesto ~10 years ago arguing for browser vendors to focus on minimalism and performance while addressing new needs via extensibility.

> I just wish WebRTC wasn't so prescriptive of DTLS/SRTP.

There was a webrtc-webtransport spec, but it got renamed to p2p-webtransport[1]. I'm not sure when the rename happened. Feels like a pretty strong indicator of webrtc being deconstructed, but whose to say this goes anywhere. We'd also need webcodecs.

It's somewhat scary & also somewhat exciting thinking of the one good, working, browser supported standard being ripped into pieces (p2p-webtransport, webcodecs, more) & being user-implemented. Having the browser & servers have a well-known target is both great but also perhaps confining. If we leave it up to each site/library to DIY their solution, figure out how to balance the p2p feeds, it'll be a long long time before the Rest of the World (other than the very big few) have reasonable tech again. WebRTC is quite capable & a nice even playing field, with lots of well-known rules to enable creative interopation. We'd be throwing away a lot. I'd hoped for webrtc-webtransport, to at least keep some order & regularity, but that seems out, at the moment. But Webrtc-nv is still ultra-formative; anything could happen.

The rest of the transport stack is also undergoing massive seismic shifts. I feel like we're in for a lot of years of running QUIC or HTTP3 over WebRTC Data-Channels and over WebTransport, so we can explore solutions the new capabilities while not having to ram each & every change through with the browser implementers. It feels like a less visible but far more massive Web Extensibility Manifesto moment, only at sub-HTML levels[2]. The browsers refused to let us play with HTTP Push, never let appdevs know realtime resources had been pushed at the browser, so we're still debating terrible WebSocket vs SSE choices; terrible. I think of gRPC-web & what an abomination that is, how sad & pointless that effort is; all because the browser is a mere glimmer of the underlying transport. I feel like a lot of experimentation & exploration is going to happen if we start exploring QUIC or HTTP3 over WebTransport. Attempts to reimagine alternatives to WebRTC are also possible if we had specs like p2p-webtransport, or just did QUIC over DataChannels. Running modern protocols in the client, not the browser, seems like a semi-cursed future, but necessary, at least for a while, while we don't yet know what we could do. The browsers are super laggy, slow to expose capabilities.

[1] https://github.com/w3c/p2p-webtransport

[2] https://github.com/extensibleweb/manifesto

I can't help but feel like this is the worst. Every time we step away from HTML & the DOM & into a further farther reach of abstraction, into something custom crafted & artisinal, we lose our valuable common heritage. We flea from common understandability & recurse into something ever more unique & virtual.

In the process- as is the case with Google Docs[1]- we lose things like the ability for web extensions to work, if this is a web hosted vscode instance (vscode server, openvscode, code-server, others). Running a debugger against this part of vscode- web or native- now yields only garbage junk information.

Right now this is just the terminal. I think- "it could be worse". But it chills me deeply that the terminal is now no longer real information. It's now just a happenstance jumble of pixels, powered by only it's own inner logic & a unique maze of libraries. Big tech keeps optimizing and optimizing, & the motive we keep being sold- this is for your good, this helps you- is one I frankly have a very hard time negotiating with myself. De-webbifying the web, de-commonizing the common platform- as Facebook has done by virtualizing the DOM- feels like this ever-running big-bang from a truthful original universe into a sparse, cold, expanding universe where each little fragment defines itself, where the common hypertext medium no longer means anything.

I keep waiting for some moments of contraction, some coming back together, for things to make more sense again, to recontract into something more solid. React's first WebComponents PR[2] is a notable re-contracting, re-platforming- a powerful act I frankly didn't expect, so rare as to feel practically unprecedented.

I realize much of this flexibility, the demonstrated versatility of the web & usage of the various pieces of it represents much of it's strength. The platform being a low-level platform where higher level platforms can be created is amazing; the Extensible Web Manifesto[3] speaks to that emergence of newer higher levels systems. And right now we're in early days, just starting a precambrian explosion of higher level web, as technology like WebAssembly only just begins to become real- still so early, still way pre-pre- Interface Types[4]/Host Bindings, only just the crudest emulation beginning in via projects like Rust's wasm-bindgen / web-sys. I am happy we are still exploding. We have so much more to exlpore. But gee I also question so much when big enterprises turn hypertext into pixels. To move compute into webassembly is a bold leap but the hypertext can survive, the DOM is still truth. It's so uncertain to me, feels like so much might be lost when giants like Microsoft or Google yank out the HTML & replace it with pixels, pushed into our faces. It feels like betrayal, like sabotage, like we're giving up truth.

[1] https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

[2] https://github.com/facebook/react/pull/22184 https://news.ycombinator.com/item?id=29505332 (16 days, 0 comments)

[3] https://github.com/extensibleweb/manifesto

[] https://github.com/WebAssembly/interface-types/blob/main/pro...

The main problem isn't CPU and GPU performance, those problems had (to some extent) already been solved with asm.js and WebGL, at least for some types of games. It's all the other APIs and the general "feature churn" in browsers which are problematic for games.

Some examples:

- The fullscreen and pointerlock APIs show popup warnings which behave entirely differently between browsers.

- Timer precision has been reduced to around 1ms post-Spectre/Meltdown, and jittered on top. This makes it very hard to avoid microstuttering (we don't even need a high-precision timer, just a way to query the display refresh rate... but guess what, there is no way to query the display refresh rate)

- WebAudio is ... I don't even know what... all we need is simple buffer streaming, and the only two ways to do this in WebAudio are either deprecated (ScriptProcessorNode) or not usable without proper threading (audio worklets), and guess what, threading is also disabled or behind HTTP response headers post-Spectre.

- Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels).

...and the list goes on. In theory there are web APIs useful for gaming, but in practice those APIs have been designed for entirely different use cases, and they are not flexible enough to be reassigned to different use cases (like games). The web needs a "game mode", or better a "DirectX initiative", a set of low level APIs and features similar to WASM and WebGL/WebGPU, and if not designed specifically for games, than at least low-level and generic enough to be useful for games.

This isn't a new idea, see the Extensible Web Manifesto:

https://extensiblewebmanifesto.org/

(backup: https://github.com/extensibleweb/manifesto)

But the ideas presented there didn't seem to have much of an impact with the web people (with the notable exception of WebGPU).