People think lots of things are good boat names. There's no reason there couldn't have more than one Unsinkable that hadn't sunk, and most boats aren't retired by sinking, so Unsinkable II would fit right in.
It's probably not attributable to AI in the way that you're thinking - Github has been absorbing an exponential increase in usage, and that increase is mostly due to new AI-related projects being created and worked on.
Though I'm sure some of the blame can go to internal slop code.
Eurosky actually looks like a promising alternative (speaking as non-european) but the AT protocol should have more open friendly competition than just the flagship instance of bluesky. Eurosky seems interesting as well.
Note that “instance” is Mastodon-brained and is a wrong way to think about atproto. The correct parallel is RSS / Google Reader.
Atproto has two types of things: hosting and apps.
- Hosting is like RSS. You can host your data on your own server and broadcast from it. It’s just an open source Docker container.
- Apps are like Google Reader. They aggregate from all hosts and usually build an index so they can show a rich view over the network. That’s what Bluesky, Leaflet, Tangled, etc, so.
So there is no “instance”. There’s hosting and there’s apps.
Your post changed my prespective on atproto! It also solidified the architectural issues I've had all along with the fediverse, and view that it's more of an interim solution which doesn't resolve the core centralisation and censorship issues; often exacerbating them to the extreme.
Just noticed who you are. Big fan of you're work and approach to problem solving! Do you have any similar posts about alternative protocols in this space, like nostr et al?
I've been ruminating on the incorporation of censorship resistance by adopting core concepts from tor/I2P and Monero using cryptographic techniques for validation and obfuscation that enable users to subscribe to specific communities, chatrooms, or channels within a PDS, so they also operate like private/public-PDS's to replace messaging providers with a uni/multi/any-cast rss. The reason I think this should coexist in the same protocol is that if the hosting provider itself is untrusted by default, and all comms are E2EE between all consumers from the ground up (public comms could contain a decryption key in the response, or one assembled by relays), the individual hosting providers can't choose to selectively filter or censor individual comms they disagree with at any layer, because they can't see the speech, where it's coming from, or where it's going; even for publicly broadcasted comms, until at least after the response has been transmitted to relays (enforced by the protocol).
I reverse proxy everything through a Caddy instance running on the same machine so I avoid the firewall dance entirely by just prefixing all my port assignments in the compose file with the loopback IP (eg. 127.0.0.1:3000:3000). Nftables denies all but 80 and 443 and I don't have to worry about restarts/flushes breaking things.
This is how I self host all my home services (Home Assistant, PFSense, Frigate etc), I do not for the life of me understand why so many folks doing self-hosted services for themselves put them on the public internet.
Caddy will even do fully automated valid TLS certificates for private IP ranges via DNS ACME challenge for free etc with renewals handled, so all my internal self-hosted sites have properly terminated TLS too, accessible by connected VPN clients.
It's funny that for many of us in our day job, we stand up private services behind a VPN all the time so only work clients can access it, but when self hosting don't bother with a simple wireguard/tailscale config etc.
A lot of people using docker or even k8s don‘t know that by default, a service is available to all other services via the service name defined in the compose file or your yaml specs. Docker compose builds an implicit bridge network. Most internet tutorials are wrong here and bing ports publicly to your ipv4 interface. So if you follow them you‘ll accidentally expose your database or similar to the public web
This is surely the easiest and I would guess the safest way, and has the added benefit that your proxy (nginx in my case) can handle SSL for you, making certificate deployment a breeze.
So what, the governance is not open and what good is a perfectly written engineering spec without the actual place where people hang out?
It’s just a lot of tech jargon masking yet-another “let’s make someone very rich” scheme.
You can be as cynical as you like but I actually tried hard to avoid tech jargon in the article. I’d appreciate you giving it a read — happy to answer questions or discuss specific concerns.
>We WANT to know that there's a collision in transmission so that we know we need to retransmit
Digital trunked public safety systems solved this problem decades ago. If you key up when the frequency is in use you get a distinct rejected tone. I'd think prevention is far preferable to sorting it out once everyone's finished walking on each other.
It also means you need to replace everyones radio at the same time because everyone needs to hear everyone on the channel.
Where new additional technologies are possible, they have been applied (digital packet networks, like with CPLDC - Controller-Pilot Data Link Communications).
Replacing A3E modulated VHF radio requires you replace it for literally everyone, because there are way more users at airport than you think.
> It also means you need to replace everyones radio at the same time because everyone needs to hear everyone on the channel.
In the public safety context it's not uncommon to phase in new systems (like digital trunked systems) incrementally. You accomplish that by simulcasting the dispatch audio over both systems, and monitoring incoming audio from both systems.
A common pattern for how this plays out would be something like this: all the fire departments and ems agencies in a given jurisdiction are dispatched using two-tone (eg, motorola) paging over a VHF frequency. New digital radios are introduced, and all the fire/ems personnel keep their existing pagers, and (some|most|all) are given the new digital radios. People without the new radios can still talk to dispatch using VHF. And of course systems can be configured to mirror audio around so that if one person is transmitting on VHF they can be heard on the digital system (usually on a channel in the 800mhz or 900mhz band). It's basically a fancy version of a repeater.
Dispatches are then given out over the same old VHF channel AND the new digital channel. In theory you can eventually replace all the old pagers and radios and quit with the simulcast deal, but IME, sometimes things stay in "parallel" mode more or less indefinitely for whatever reason[1]. That said, to your original point, you typically do want to get at least radios standardized as much as possible, even if you maintain the split for (paging|operational communications).
To illustrate, two jurisdictions I'm familiar with: Orange County NC, and Brunswick County, NC. Both followed the path I talked about above: all VHF dispatch for fire/ems, then adopted the NC VIPER digital trunking system, but continue to page on VHF and simulcast the dispatch information over both channels. I'm not sure exactly when Orange County adopted VIPER but it's been quite some time and they're still doing both. FSM only knows if/when they'll ever completely abandon the old VHF system.
[1]: and that reason is often as simple as "money". Plenty of volunteer fire departments in rural areas are skating by with barely enough money to keep their apparatus road-worthy. Replacing every hand-held and mobile radio they own in one fell swoop is often out of reach.
[Source: was a firefighter and 911 dispatcher in a previous life]
You're writing about experience in a closed system - as far as I know all such dispatch systems for public safety etc are closed system where everyone who is ever going to be on the net is part of the system, and it might at most be a case of "we don't have money to replace every member's radio".
In comparison, aviation radio is an open system - not only you do not know who is going to communicate, the communication is also peer to peer, unlike many digital trunked systems which often depend at least on some level of cellular support system.
The only "access control" on the airband VHF and HF comms is of legal variety, with explicit carve out that the person actually flying the aircraft is way less bound by legalities in case of emergencies, and everyone has to be able to talk with everyone, especially on one of the standard common channels.
Examples from personal experience involved various combinations of small airfield ATZ, MiG-29, gliders, old ursus tractor (agricultural kind), busted up Opel Kadett, airliners, ultralights, small transport planes, private helicopters, and dunno who was responsible party but helicopter working as diplomatic flight.
All on one small airfield. And every one of those had to communicate independent of each other with everyone else on that list.
The only time we do "rebroadcast" is when we end up having to do a manual relay due to distance, which is also one of the rare cases where comms might switch over to a more modern system, because someone could ask ATC over VHF to pass something over CPDLC to airliner or using HF, and vice versa.
The poor A3E modulation on VHF airband is the lingua franca, the lowest common denominator, which allows random aircraft from anywhere in the world talk to another random aircraft, as well as ground.
