-

2023-01-12 17:12:09

adminsforum@hubzilla.org

ray peaslee wrote the following post Thu, 12 Jan 2023 17:12:08 +0100

If a user removes their account using the removeme page is there a period of time that has to go by before they can register again?
Thanks

- - -

2023-01-14 10:07:22

Scott M. Stolz

scott@loves.tech

So far, the solution seems simple.

1. Herd all of the fediverse cats.
2. Get them to implement the desired technical changes allowing key changes and reuse of channel addresses.
3. Issue standards on how to display that channel@example.social and channel@example.social are actually different channels / people.

Easy. Especially the herding cats part.

But seriously, permanently banning channel addresses may work in the short term, but it is not sustainable. As was mentioned, some major organization, such as a school or government agency, is going to screw up their instance/hub, and permanently banning admissions@example.edu because they broke their website and reinstalled would not go over well.

So it might be something worth working on with ActivityPub and other protocols.

2023-01-14 10:51:16

Scott M. Stolz

scott@loves.tech

I decided to start a topic about it ActivityPub's forum, SocialHub. I'm curious about their perspective on it.

#^https://socialhub.activitypub.rocks/t/reuse-of-identity-channel-addresses-revocation-reissue-of-keys/2888

2023-01-14 20:19:00

Mike Macgirvin

mike@macgirvin.com

To be fair, this isn't the first time this conversation has come up. It's another one of those recurring rabbit holes that surfaces occasionally.

I can still remember when I was full of enthusiasm that I could fix it. And for the most part we did (as I had a fair bit of help). In a Nomad only world the problems are pretty much solved - but there are bugs to fix. Start there. Every single hubloc query that searches by address needs an "ORDER BY hubloc_id DESC" clause. Somewhere in Hubzilla there's still at least one place this is not happening. In Streams, there are also places where this should be fixed, though I've checked them all and left a few that shouldn't cause any problems. Even if it doesn't cause an issue today, we should still get in the habit of doing this to support re-installs anywhere we check identity.

The next thing you can do is implement Identity Proofs under ActivityPub.

https://codeberg.org/fediverse/fep/src/branch/main/feps/fep-c390.md

I consider Diaspora a lost cause at this point - unless somebody forks the project and converts it to ActivityPub. If you wish to still converse with that network, you should always start with a fresh channel they've never seen before. There's nothing more you can do. They do have a re-key operation associated with their account migration procedure, which might be useful as long as you never create a clone in our network, which that operation will likely destroy.

Be aware that Pleroma can change keys whenever they like and doesn't notify anybody. This makes it incredibly difficult to figure out if a Pleroma identity is getting re-used.

Re-keying is already provided as a protocol primitive in NomadHandler (Zot6Handler if you're using the older protocol). External network re-keying is provided in our implementation of Mastodon's 'movedTo' operation. Dead account detection (for channels that go away without telling anybody) is provided by Hubzilla's global directory - although this was tossed in streams because it doesn't work with the rest of the fediverse and has become a spam magnet.