Nostr notes by ShutterBugged

If it's purely federated-auth, then you would continue to ...

2026-02-12T10:25:17Z

In reply to nevent1q…ew3h
_________________________

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"

Maybe this isn't an issue at all? If you need a ...

2026-02-12T10:03:21Z

In reply to nevent1q…53h4
_________________________

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.

I suppose that's expected if you've chosen to push that ...

2026-02-12T10:01:18Z

In reply to nevent1q…dvr4
_________________________

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.

tbh, I think that's a can of worms you don't want to open ...

2026-02-12T09:40:27Z

In reply to nevent1q…pkwr
_________________________

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.

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

2026-02-12T09:13:51Z

In reply to nevent1q…43pn
_________________________

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

You mean having two accounts that mutually point to each other as ...

2026-02-12T09:12:40Z

In reply to nevent1q…48ud
_________________________

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.

I think it could be done without rethreading history, just ...

2026-02-12T08:49:21Z

In reply to nevent1q…8r96
_________________________

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.

Asking forgiveness instead of permission, so to speak, and going ...

2026-02-12T08:32:37Z

In reply to nevent1q…sa0l
_________________________

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

I was actually _literally_ suggesting registering "local" ...

2026-02-12T08:31:29Z

In reply to nevent1q…x6ks
_________________________

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."

And of course this would become way simpler with support for ...

2026-02-12T08:16:44Z

In reply to nevent1q…3uwf
_________________________

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."

I think someone could even push in this direction this today, ...

2026-02-12T08:15:55Z

In reply to nevent1q…tg22
_________________________

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.

I've asked myself for years if revolt (now stoat) could be ...

2026-02-12T08:11:00Z

In reply to nevent1q…7r2c
_________________________

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.

There are dozens of papers that bear this out, with more every ...

2025-12-31T01:43:15Z

In reply to nevent1q…rdkq
_________________________

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.

You don't need multiple cameras for the same reason you ...

2025-12-31T01:39:43Z

In reply to nevent1q…rxxr
_________________________

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.

It's also a common fallacy to think you need a 3D sensor for ...

2025-12-30T00:17:20Z

In reply to nevent1q…7u9v
_________________________

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.

You're vastly overestimating the weight of these models. ...

2025-12-30T00:08:34Z

In reply to nevent1q…sga9
_________________________

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.

Not a small task to be sure, but the algorithms are out there and ...

2025-12-29T22:19:49Z

In reply to nevent1q…9ga4
_________________________

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.

I've seen research results firsthand (published in something ...

2025-12-29T22:19:09Z

In reply to nevent1q…w2hl
_________________________

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.

Rewriting language?

2025-01-09T04:34:50Z

In reply to nevent1q…0aw4
_________________________

Rewriting language?

not TOCTOU safe 😂

2024-08-07T19:02:34Z

In reply to nevent1q…r5gm
_________________________

not TOCTOU safe 😂

Would there be a better way to generalize kexec or a mechanism ...

2024-07-09T03:46:15Z

In reply to nevent1q…kzk8
_________________________

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?)