OneDeuxTriSeiGo

Tbh I have no idea. I kept up with it on the GrapheneOS discord and I think GOS put out bluesky/mastodon posts about it at one point.

What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?

Well now I think the last major barrier is cleared (which was E2EE being nonstandard). Currently the on-device infra is very google-oriented but there is support for non-google-jibe RCS but it still requires google, etc to explicitly opt-in apps to get access to the APIs on device.

A big part of this IMHO is google refusing to give up their moat but they may finally get it into AOSP at some point.

If they don't at this point I think the only way it'll happen is if the EU forces their hand (which they hopefully will do).

So the issue with RCS is that google just this last year made the move from their internal implementation of E2EE for RCS to the standard implementation based on MLS (now that the standard impl is actually viable).

They did this quietly in the background and most people didn't notice but in doing so they released new system/OS level services and started relying on those. And notably they did this rollout staggered such that only some people got it and some didn't which made everything way more confusing.

GrapheneOS has a bunch of security hardening to restrict crosstalk between apps and services and the assumptions GOS made and the assumptions Google made about how services and apps should be allowed to interact were disjoint. That mismatch in assumptions broke things for a while. And the lack of clear communication from Google about this change combined with various anti-spam/rate limiting issues (Gmessages kept trying to register not expecting to fail and kept slamming the servers which looked like spam and triggered exponential backoff retries) compounded together to render RCS broken for a few weeks during that migration.

Notably this was also broken for basically every other non-google/non-samsung android provider for a while as well due to how poorly the migration was communicated by google.

Then not long after that was resolved graphene changed how they handled their sandboxing to make it less brittle to google changes and since then there's not been much in the way of issues.

The only issue with RCS since then has been a brief break in RCS (~1-2 days) about a month ago due to what was essentially an update to Google's services putting the graphene sandbox briefly out of sync. This was fixed almost immediately on the alpha release channel and just took ~48 hours to move through the alpha->beta->stable pipeline.

From this point on now that RCS is more or less all "standard" stuff now you shouldn't see any major breakages. The only situation where you might see one would be when android inevitably opens up RCS outside of the google services walled garden but even then you should be able to continue relying on the google services version until the non-google version is stable.

Kagi nowadays has a feature called "SlopStop" that you can opt into. It's basically a global block list for LLM generated websites, etc that is shared across all users who opt into and anyone can report sites/content to it.

Kagi of course reviews it but generally it's good enough that I don't see much LLM generated content in the results anymore.

fwiw tangled itself is also an appview and they are gradually working on rebuilding it around their new XRPC oriented appview called bobbin.

The appeal of bobbin is it's fully stateless and pretty lightweight. IIRC you can run all the infra to run a proper tangled appview (including bobbin) all on your average lower middle end general purpose cloud instance.

That's the advantage of picking a theme. So the project is called tangled. So everything is string/web themed. Knots, spindles, bobbins, etc

I'm not sure what's been published but as someone who plays with tangled as a hobby the immediate monetisation paths I could see are:

- Charging to bypass the (admittedly very reasonable) rate limits on the main appview

- Providing paid hosting tiers for private git knots, high traffic git knots, git LOP knots, CI runners/spindles, web page hosting (via their github pages equivalent), etc

- Introducing a paid-for and permissioned nix binary cache platform since their CI spindle system is already nix-first.

- providing paid PDS hosting for corporate/business customers with SSO integration etc.

- SLAs and support contracts

There's enough options here that they have a pretty flexible path towards profitability.

It absolutely is. Mastodon has rate limits and administrators have to manage and adjust them as necessary for their instances.

You probably just don't notice it as a user or as the operator of a small instance which to be fair is exactly the same with atproto. Users rarely notice rate limits and small operators rarely do either. It's the operators of large services that see these limits and have to coordinate with other operators.

The issue with W social is that they have a chronic inability to coordinate or play nice with anyone else in the atproto space. Rate limits aren't a problem if you are a good neighbor and you know your neighbors but frankly they just don't.

It's not that they didn't warn bluesky specifically. It's that they didn't warn relay operators in general. And IIRC they just needed to coordinate with a single relay operator who is reasonably trusted (ex blacksky or eurosky) but they didn't do that either.

The default rate limits are quite reasonable but big launches will blow past them so you gotta coordinate with someone.

And note that the relay federation/gossip agreements are largely manual configuration at the moment. Until someone pushes a proposal for an automated/dynamic topology management algorithm that doesn't get plagued with spam issues it'll stay this way.

Technically it has moved (last year actually) but it just doesn't really look all that different in the day to day.

https://atproto.com/blog/plc-directory-org

The distinction really kinda depends on the situation.

FDEs have been around for a long time in the defense contractor space and Palantir picked up the term, broadening the meaning a decent bit. Then it spread to the rest of the software/tech space.

Historically FDEs in defense are engineers who would literally forward deploy out to other countries where the hardware was being deployed so that they could provide on the ground hardware and software support. They'd either literally be called FDEs, Engineer (forward deployed), field engineer, or some other title that roughly got the meaning across.

You'd deploy some platform and send along an engineer or two and a few technicians. Depending on the platform or the scale of the deployment the engineers would either be normal engineers forward deploying for a few months to a year or so or you'd hire a dedicated FDE for that given deployment/site.

AFAICT it became a lot less common as internet communications got better and you could do practical remote debugging and live video conferencing but you still see FDE roles in the traditional sense from time to time.

But yeah then Palantir and big tech came along and basically rendered it into a glorified consultant and/or systems integrator role.

Yeah definitely but tbh a one-off expense at that scale while unfortunate isn't really lethal.

And tbh if you are performing ops at a scale where that level of expense is present it's nobody's fault but your own if your orchestration is cronjobs on the 58th second of the 59th minute of the last hour of the year.

And at any time scale past the order of seconds, this is a small enough time jump that it's a rounding error in ops expenses.

That shouldn't be the case?

When a negative leap second is applied it just means that 23:59:59 is skipped. The seconds go 56 57 58 0 1 2 3.

vs a positive leap second where time goes 56 57 58 59 60 0 1 2 3.

So if you are billed by time and it's tracked via a timer then your time is still accurate but if it's tracked by reading your start and end time then your billing will just read an extra second.

Positive leap seconds are harder as they require you to reason about a clock that includes a 60th second but systems view negative leap seconds as if nothing happened for an entire second.

Now there are some cases where this runs into issues. If you have jobs that fire off based on the time then you can get jobs running a second early. Normally this shouldn't be a problem but in some cases this could result in contention of resources.

You could also accidentally trigger watchdogs but any watchdog worth its salt will use a real timer not wall time.

But overall negative leap seconds are way easier as they are still monotonically increasing and don't require downstream systems even understanding the concept of a leap second in the first place.

This is also something where how you interact with the IRS really really depends on your initial interactions.

If the IRS comes to you and says "your taxes are wrong you owe X amount" and you immediately turn around and prepare to fight them then they are going to be merciless with you.

But if they come to you and you turn around and show the auditor your methodology and what you thought you were supposed to be doing, etc and focus on fixing the issue and settling your debt then they are going to hook you up with IRS staff dedicated to helping fix this kind of stuff.

And most importantly they'll connect you with someone who can set up a payment plan out over whatever period of time to pay back what you owe without killing your business or taking your assets.

But again if you get audited and immediately become adversarial then they'll assume you were doing it intentionally and will take anything not bolted down.

-----

The rationale is basically that the IRS staff are mostly there to help you get your taxes in order and ensure that those taxes are paid but as soon as it starts to look like you are intentionally avoiding paying your taxes you get kicked over to the enforcement divisions and eventually the criminal divisions.

So good faith is absolutely something the IRS will honor but that stops the moment it looks like you are trying to hide stuff from them.

That's a leadership failure not a technical failure. If you can't dig your heels in and force time to tidy up technical debt then you need to find someone who can and let them take over as PM.

DKIM2 and DMARCbis are actually the opposite of this. They are long awaited fixes of brittle and often broken systems that are designed to now make providing secure email easier rather than harder.

They both have fairly clean migration paths and resolve a lot of the annoying edge cases that currently exist with authenticating and verifying email.

NGL I'd argue there's a certain appeal to "use AI to prototype a feature as fast as possible and focus your engineer hours on building a comprehensive testing and fuzzing plan" followed by a "remove and review everything that can be cut without breaking the tests" cleanup pass.

Hot melt ink/solid ink has a laundry list of problems that complicate it.

- A single ink clog can destroy a printhead.

- partial clogs can result in ugly messes with ink smeared all over the pages and the assembly further smearing on later prints.

- the printer has to be calibrated to the specific formulation of solid ink to work properly. A bad ink batch or calibrating to the wrong formulation (or a drift in specs on the formulation) can cause clogs, print head failures, etc.

- solid ink printing massively complicates lamination if that's something you need to do (ex in an office).

Overall it's a far more unforgiving process. You can't really have aftermarket inks like you can with modern inks and even variations in the first party manufacturing process can have catastrophic effects on the print hardware.

It's incredibly childish of people on this site that within minutes of you posting people are trying to downvote you for saying "don't say slurs".

NGL I can't imagine casually throwing slurs around having been acceptable on HN 1, 2, or even 5 years ago yet here we are.

It's not literally IPFS but atproto/bluesky is using most of the bones of IPFS (IPLD) to do their entire data propagation and event broadcasting.

And tbh it shouldn't be terribly difficult to extend the existing infra to supporting a full IPFS based system but I don't think anybody has considered it worthwhile yet.

ATproto uses just the bits it immediately needs even if it could probably benefit from the other parts long term (ex for archival relay stream preservation).

The purpose of signing your emails or commits is to provide a good indicator that it actually came from you, not someone who managed to get access to your email account at the time.

This is true and it's still true in the ATProto ecosystem but in a different context.

It asserts that events and records are authored by your PDS, not by you specifically. Which is certainly closer to the intent of TLS certs.

And technically you can maintain a PDS proxy that can only host, broadcast events, and receive content but that doesn't have any keys or signing capabilities.

Then you can have a local PDS that does your signing and sends signed events and records (basically signed state updates) to the PDS proxy to actually emit to the network. This then allows you to lock your keys behind a hardware key to better lock everything down. Of course there are trade offs to this. If it requires physical auth then it can only work on one device at a time or you have to self host it homelab style at which point it might just make more sense to host the PDS yourself anyways.

There's a project thats working on this very thing but I've not kept up with it and I can't remember what the name of it is. If any ATproto people in the comments knows the name/link feel free to reply under this to enlighten me + everyone else.

Kind of. Your PDS can impersonate you but you can have higher ranked "recovery keys" that can undo/recover all the damage.

Socially whether you can explain off that your PDS acted maliciously or that it was hacked or whatever is a different story but if you keep recovery keys for your DID you can take back control and undo everything your PDS did that you didn't authorise pretty trivially. The UX for it needs to be improved but technically the process is super simple/straight forward.

And those recovery keys provide a mechanism for declaring "hey i didn't do this I was hacked" on top of specific events but nothing for taking advantage of that cryptographic opportunity has been built out yet.

Note that you don't have to have a social account. And there's work on the semi-distant horizon for creating sub-accounts which are independent but all under a common top level account kinda like how GPG conceptualizes subkeys or cryptocurrencies handle derivation keys.

For the current moment though you can just create an atproto account without creating a bluesky account. Tangled for example supports this on their site by creating one for their PDS and you can always move to another PDS in the future.

The over-arching idea isn't that your code is tied to your socials but rather that you can have a bunch of disparate services that you can interlink over a common identity layer and that those services are only loosely tied to the people/orgs hosting them but could be trivially hosted by anyone else.

Users of different appviews are just using a different aggregator/backend in effect. The network is still largely the same but there may be minor moderation or feature differences between appviews.

Users of different PDS would be the closest thing to a mastodon instance and there's thousands of different PDS without much issue. I'm on a "third party PDS" and I've had barely any issues.

I use a "third party" PDS, appview, PLC directory mirror, CDN, and client so 99.9% of my interaction with bluesky and atproto at large is independent of bluesky the corporation.

Despite using a third party "basically everything" my experience is essentially the same as a "default" bluesky user if not better in many ways

huh? the only Δt in the article is used correctly.

With 18× 140 mm of surface, the fans run quietly and the coolant Δt across the rads stays small

It's been years now and that's still little more than a conspiracy theory. I don't think it has much bearing in real world policy discussion.

It's not really the same thing. If we exclusively tested coronavirus with PCR tests it'd be a lot more similar but the presence of kit tests and "30 minute covid testing" really muddied the water.

And of course Covid tests are primarily mucous membrane based which is going to be inherently harder to evenly test compared to a blood sample where viral load is pretty evenly distributed.

At least for blood based diseases, detecting viral load via PCR testing is to such a sensitivity that if there's essentially any active viruses out and about or any active viral RNA floating around in cells then the tests come back positive.

And with sustained antiviral use testing is less about "do I have it/will I become contagious in the near future" (like coronavirus) and rather "is my antiviral regimen still killing the virus faster than it can wake up from latent genetic material sleeping in DNA".

The former is a timing problem from one shot testing the latter is monitoring a steady state to track that the treatment remains effective and when it ceases being effective there's a lag time between viral load being detectable and sufficient viral load to be meaningfully contagious.

Yeah HSV on its own would be awesome to find a good vaccine for but the insights it would give for vaccinations against the broader human herpes virus family would be massively impactful.

A successful HSV vaccine would also almost certainly lead to a vaccine for epstein-barr, cytomegalovirus, and roseolovirus.

Even ignoring the thousands of connections HSV is suspected to have to other diseases, getting insight towards the other 3 big "uncured" HHVs would be a massive deal.

EBV/mono is a silent but debilitating disease that infects a near majority of the population even in "developed countries" and is all but confirmed as a requirement for developing multiple sclerosis. EBV is also directly connected to a long list of cancers as well.

cytomegalovirus and roseolovirus while less common in the developed world are still far too common and globally are major sources of harm for infants and young children.

Any steps towards effective vaccination against the broader family of HHVs would be monumental.

You are confusing it with HPV (human papillomavirus). Hep B is a very different disease.

The first Hep B vaccine in the US is given to all infants within 24 hours of birth (unless the child is already positive for Hep B or severely underweight). And then the second vaccine a month or so later and the third between ages 6 and 18 months old. Hep B vaccination is one of the most common vaccinations received in the US.

And also as a fun little fact the first Hep B vaccine was given exclusively to gay men for a decent while until it was deemed safe enough for the general population. It was also manufactured from the blood of gay men and needle based drug users.

The Hep B vaccine that came later was recombinant and that one was given to everyone from day 1 and that's the vaccine that's been more or less the main Hep B vaccine in use up to today. Recently there's at least one new one that has been approved but the original recombinant Hep B vaccine is still regularly given.

I really like the approach but it'd certainly be nice to be able to use alternate topologies.

Also it'd be nice if there was an underlying grid plotting the metric/distance function to help conceptualize distance/relationships better when you get to the edges.

That's less because it was Bitcoin and more because the entire effort was a slapdash affair pushed by Bukele in an effort for him and his buddies to profit off the cryptocurrency boom rather than being an inherent knock on cryptocurrency itself.

Also of all the cryptocurrencies Bitcoin is a pretty poor choice since it could be pretty well argued that it has lost the original purpose and devolved into a raw "line go up" financial instrument.