Curious why you're running a mirror for OSM, is it public or for your private use? If you don't mind, I'd love to learn more about it; sounds super interesting to me.
Worth mentioning the story of John Barnett (RIP) here too:
John Mitchell Barnett (February 23, 1962 – March 9, 2024) was an American whistleblower who was known for his substantiated safety and quality reports to the Federal Aviation Administration (FAA) about Boeing's production of the Boeing 787 Dreamliner and death which occurred amidst a lawsuit he brought against Boeing. Barnett worked in quality control at Boeing for 32 years, serving for seven as a manager in North Charleston, South Carolina.
In March 2024, after he failed to report for his third day of deposition, he was found dead of a gunshot wound.
The Web is the single most successful application platform of our day and age: it’s free, open, and unencumbered, and it’s cross-platform, available on expensive iPhones to sub-$250 Android phones just the same. Let’s make sure it stays that way.
For the attachments like pdf you can use webdav, but for the metadata you have to use their service [1]. They have the code repos online so it's open source, but no self-hosting instructions [2]. They claimed it to be due to technical difficulties [3], though imo they have no incentives to provide this given that they host a paid service themselves.
I've installed the app linked in TFA and it immediately asked me to sign in or sign up without any option to configure my own server address. But since it's still a beta version, the custom server/local only options are probably not implemented yet.
As far as I know, Jitsi uses SFU (i.e. not P2P, not MCU), so every device sends their stream once (to the server), which doesn't do any transcoding but only forwards the streams to each client.
Therefore (just like multicast) you only send your stream once, and every client receives n streams.
How is this significantly different from n-1 streams coming from a single peer/server connection? Isn't that simply what it takes to have a group video call?
> Twitter is important because it's a new protocol. Fundamentally it's a messaging protocol where you don't specify the recipients. It's really more of a discovery than an invention; that square was always there in the periodic table of protocols, but no one had quite hit it squarely.
Successful new protocols are rare. There are only a handful of commonly used ones: TCP/IP (the Internet), SMTP (email), HTTP (the web), and so on. So any new protocol is a big deal. Each one of those protocols has spawned many successful companies. Twitter will too.
> We want to fund those companies. And the people at Twitter also want to encourage people to build stuff on top of it. So together we came up with a plan: anyone YC funds to do a startup based on Twitter will get priority access to the Twitter stream, and to people at Twitter.
> It certainly doesn't seem as promising a territory as it used to. Not so much because it's more dangerous as because Twitter hasn't turned out to be a "platform" in the same sense as say iOS has.
IANAC† but I think the use of Noise Protocol is completely bogus. Regardless of your protocol of choice, you cannot encrypt things end-to-end if you cannot authenticate who is at the other end that you're encrypting for—hence the use of "safety numbers"[0] in Signal, "certificate authorities"[1] in TLS, "web of trust"[2] in PGP, and the list goes on and on...
This is at best an obfuscation attempt to make fingerprinting more expensive, just like BitTorrent protocol encryption[3].
Hi, I wrote this post. Let me use your comment as a chance to talk about what I was going for with the use of Noise here.
You're correct that part of the assumption inherent in end-to-end encryption is that you've got the other end right; otherwise, MitM attacks become possible. To prevent this, Social apps like Signal (also WhatsApp and many others) give you, roughly speaking, a way of confirming that both endpoints have negotiated the same secure channel. Less-social web apps use PKI. In both these cases, the design makes sense because you care who the other endpoint is. Their identity is meaningful to you outside of the context of the protocol.
In the peer-to-peer context, though, this identity information is mostly meaningless. I think, as long as there are no "network admins" or similarly privileged identities worth claiming, it's less important to certify identities up-front (what would even be a reasonable standard for accepting them?) and it's more important to be able to persist them. You want to make sure you're still talking to the same person you were talking to last time, whoever they are. This is what the PSKs are meant to accomplish (though they are not the only possible solution here).
This is technically still MitM'able, but only if you catch two parties on their very first connection; after that, they have a shared secret, and you should be locked out. Technically this falls slightly short of the ultimate goal of end-to-end encryption, but I still think it's a good fit for this context.
> Starting with v0.3.0, Iroh is a ground-up reimagination of the InterPlanetary File System (IPFS) focused on performance.
Also see, A New Direction for Iroh[1].
[0] https://www.iroh.computer/docs/
[1] https://www.n0.computer/blog/a-new-direction-for-iroh/