1/3

naturzukunft

1/3
At the moment I'm questioning the whole webfinger story.

I use uuid internally to identify actors.

and with webfinger you can currently find an actor URL using the preferredUsername.

here some verifiers are already complaining that the URL doesn't match the requested name. <- I really question that.

But now I'm so cheeky and sometimes delete my dev database. So @[email protected] gets a new uuid!

#activitypub #activitypubdev

naturzukunft

2/3
And then there's a huge crash, because some instances cache max's profile and therefore have old URLs.

Now there are claims that (if you work properly) you send a delete activity before deleting the DB.

OK, yes I could understand that somehow. But where do I send this delete activity (or update activity if the inbox URL changes, for example? Because I get a lot of delete activities from whoever).

#activitypub #activitypubdev

naturzukunft

3/3
AND:
Suppose max changes his name to @[email protected]. And @[email protected] notices this and is happy that max is finally free and changes his name to @[email protected].
Now @[email protected] sends a note to @[email protected] and since the profile is cached, the wrong max now gets a create note activity, right?

So somehow this is either not quite right yet, or there is a knot in my head.

#activitypub #activitypubdev

marius

@naturzukunft I think that applications that require the canonical remote representations of actors to match their current internal state and break if it does not are plainly wrong.

Marcus Rohrmoser 🌻

Hi @naturzukunft,
IMO there is a lot of overcaching. In fact, there is few you can really cache. Invalidation being one of the proverbial 3 hardest problems in IT.

But seriously - the actor id url is the relevant thing. The #Webfinger address is no more than a shortcut. Not being part of #ActivityPub but supplemental.

And once the (actor) id changes, things are to break.

Nordnick :verified:

@mro @naturzukunft

If you reuse an address, don't you give it a new key? Or was this meant with crashing on remote instances?

naturzukunft

The UseCase that I have when deleting the DB in the dev environment is certainly not a real one. But caching the actor brings other problems with it, which in my opinion are relevant. Bsp. https://mastodon.social/@naturzukunft/113504911553531007
what is your opinion on renaming ?

naturzukunft

@nick
if
https://dev.rdf-pub.org/0815 (@Max@ dev.rdf-pub.org)
changes he's name, it results in:
https://dev.rdf-pub.org/0815 (@Maximilian@ dev.rdf-pub.org)