oh nice is there a tracking issue for this somewhere? I've taken a peek at the issues in the org on github but i didn't see one off the bat (mainly because there's a ton of other SMS related issues that pop up from history)
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.
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.
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.
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 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).