ShutterBugged

https://mastodon.social/@developing_agent

Profile image: image of a camera lens and shutter.
#nobot #noarchive #nobridge #nothreads #nometa #noai

Public Key

npub1k2h3zckgdsldhw7j7a3yrz2kvu0faqj7sqgaewm9wd6ckst8s30sz2txtd

NIP-05 Address

developing_agent_at_mastodon.social@momostr.pink

Profile Code

nprofile1qqst9tc3vtyxc0kmh0f0wcjp39txw857sf0gqywuhdjhxavtg9ncghcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds78u5w4

Publishing to

offchain.pub

relay.damus.io

nos.lol

Author Public Key

npub1k2h3zckgdsldhw7j7a3yrz2kvu0faqj7sqgaewm9wd6ckst8s30sz2txtd

Show more details

Last Notes

2026-02-12 10:25:17 UTC

- reply

If it's purely federated-auth, then you would continue to have one and only one account on each server (only method of auth changes), so a remote "homeserver" account and the "local" account would never appear alongside each other.
At the time of the transfer of login authority, the account type on the remote server would undergo some remodelling, so eg. when someone mouses over your profile in posts on remoteserver it says you're "person@otherserver" instead of just "person"

2026-02-12 10:03:21 UTC

- reply

Maybe this isn't an issue at all? If you need a federated-auth client to set up the federated-auth account you're migrating control to, then you can be sure as a server designer that people have such a client by the time they migrate.

2026-02-12 10:01:18 UTC

- reply

I suppose that's expected if you've chosen to push that particular button (would it only be possible from such a client?), though it doesn't give people the option to go back obviously.

2026-02-12 09:40:27 UTC

- reply

tbh, I think that's a can of worms you don't want to open if you don't have to. It's already standard practice to log someone out everywhere when their password changes, and this is a much bigger change to their account that that. Maybe if there's a waiting period it only happens at the end of the cooldown when the result finally sticks.

2026-02-12 09:13:51 UTC

- reply

Not sure what you mean by the "multiple clients" case.

2026-02-12 09:12:40 UTC

- reply

You mean having two accounts that mutually point to each other as "I log in other there"?
I think it might be an unlikely race condition if it requires manual conversion as exists in mastodon. But I think two problems could be solved at once with a cool-down between pushing the button and actually becoming a non-local account. If servers refuse to become that external authenticator during the cooldown that might fix it, and it ads a guard against hostile takeover.

2026-02-12 08:49:21 UTC

- reply

I think it could be done without rethreading history, just changing the user account type so that the server knows to go elsewhere for auth. Then sending new information to the client whenever you're talking about a truly non-local account....
...actually, the hardest might be trying to handle other people who are also running multi-server clients, clientside in the initial bodge-client. Thinking about that makes my head hurt.

2026-02-12 08:32:37 UTC

- reply

Asking forgiveness instead of permission, so to speak, and going ahead and building a client anyway.

2026-02-12 08:31:29 UTC

- reply

I was actually _literally_ suggesting registering "local" accounts on every server and letting the client manage the credentials. Yes, this is incredibly, incredibly dumb.
100% agree that it would be better to get scoped users and federated authentication going as official parts of the protocol. This was just a thought experiment in "what could we do if we had to go it alone and were willing to break the rules a bit."

2026-02-12 08:16:44 UTC

- reply

And of course this would become way simpler with support for portable identity, even something simple like the openID connect we had in 2005-7. That way you wouldn't need to create an account on each new server, you could just tell it "I log in over here."

2026-02-12 08:15:55 UTC

- reply

I think someone could even push in this direction this today, without *any* work on their side. They allow 3rd party clients, explicitly. Building one which could remember the credentials for and connect to multiple servers (computers) and display all the servers (chatrooms) and DMs on those (computers) in one UI would be a big step.
Invite links to join other servers (on other servers) could probably be handled client-side too, though handling DMs might be a little hairy.

2026-02-12 08:11:00 UTC

- reply

I've asked myself for years if revolt (now stoat) could be molded into something like that. People have been pushing them for *ages* to "add federation" but the limiting factor has always been that the team is a tiny group of volunteers.

2025-12-31 01:43:15 UTC

- reply

There are dozens of papers that bear this out, with more every year. I have colleagues working in sports analytics who were working out the forces through the bones of hockey players from a single TV camera viewpoint captured from 100 feet away. You can get high quality poses from very restricted data when you have a model that has internalized how human skeletons behave.
The biggest problem is that the papers get posted, the code/checkpoints get put on github, and then people move on.

2025-12-31 01:39:43 UTC

- reply

You don't need multiple cameras for the same reason you don't need a depth sensor. You're not determining the pose of an arbitrary tree of 17 random points in 3D space. It's a human skeleton, and human skeletons have extremely limited variation, even if you're comparing a child and Robert Pershing Wadlow.
3D vision and depth sensors really, actually, *do not matter.* The benefit is homeopathic with the benefit of a model that's been trained to estimate human poses with good ground truth.

2025-12-30 00:17:20 UTC

- reply

It's also a common fallacy to think you need a 3D sensor for high-quality 3D work. (indeed, state of the art SLAM systems like OrbSLAM3 are typically monocular)
The models used typically label bones and then make a good guess on what the depth of the bones should be given typical human proportions and typical human poses. (depth cues) They're trained from researchers dancing in front of more expensive sensors like the one you linked, but provide near-identical output in their absence.

2025-12-30 00:08:34 UTC

- reply

You're vastly overestimating the weight of these models. We're talking about a couple layers suitable to run in realtime on a CPU, or even lighter non-network models.
These are not even remotely in the same class as the "AI" du-jour.
I'm also not talking at all about face tracking. I'm talking about body tracking with tagging of bodyparts in the image and refinement of the pose by guessing at the depth of the end of each bone.

2025-12-29 22:19:49 UTC

- reply

Not a small task to be sure, but the algorithms are out there and it seems such a shame to see people spending lots of money on iphones and vives and tracker suits when it could be so much cheaper.

2025-12-29 22:19:09 UTC

- reply

I've seen research results firsthand (published in something like the last 3-4 years) that could do as well if not better with an inexpensive webcam or two with machine learning to refine/interpolate the poses. It would be a massively cheaper system, and would "just" require someone to benchmark a few of the research-grade python codebases floating around and "operationalize" the winner.

2025-01-09 04:34:50 UTC

- reply

Rewriting language?

2024-08-07 19:02:34 UTC

- reply

not TOCTOU safe 😂

2024-07-09 03:46:15 UTC

- reply

Would there be a better way to generalize kexec or a mechanism like it to support this kind of thing?
(Something where you pass the curent state of the hardware forwards, and maybe skip init modules for stuff already set up until you get to a final shim that assumes maximum init?)