@[email protected] @[email protected] @[email protected] @[email protected] @[email protected]

Nordnick 🐘

Why do you consider the "publicKey" of an #ActivityPub actor to be volatile?

And #Webfinger is used to translate.

So acct:[email protected] is using the aliases https://digitalcourage.social/@mro and https://digitalcourage.social/users/mro. It also defines links for HTML and JSON. Why do you consider this to be volatile?

Marcus Rohrmoser 🌻

Hi @[email protected] @[email protected] @naturzukunft,
I consider that volaile, because no standard promises nor technical means guarantees otherwise. It can change without notice any time at will of the other side. It can become invalid, inappropriate or even dangerous to use any time. Think revokes and deletions for peculiar reasons. So it should be up to date and recent when used.

The same holds for the #webfinger name.

I guess you disagree, why?

P.S.: I am not talking about a specific product or version, but AP and #RFC7033 in general and a #diverse range of implementations including but not limited to the one of @aSeppoToTry

Nordnick 🐘

@[email protected] @[email protected] @[email protected] @[email protected]

I agree, that this information should be refreshed after some time. So information, that is several years old, may be considered being invalid now...

I don't consider #ActivityPub actor information as being volatile. Basic actor identification isn't supposed to be changed every some seconds. It wouldn't be useful at all.

Also fetching all information again every time doesn't look efficient and would create unnecessary traffic.

Btw.: Taken from RFC 7033:
A #WebFinger resource can include cache validators in a response to enable conditional requests by the client and/or expiration times as per Section 13 of RFC 2616.

So we can talk about the interval of refreshing, but it should be assumed, that remote actors are stored locally in an #ActivityPub instance.

P.S.: Regarding seppo.social, as it looks like, this is your project: On a first view, it doesn't seem to provide a proper nodeinfo and also doesn't support a shared inbox!?!

naturzukunft

@[email protected] @[email protected] @mro @aSeppoToTry
so my users will be allowed to change their preferredUsername at any time and I see no reason not to allow this for other user settings!
outbox / inbox url e.g. will behave more stable.

Nordnick 🐘

@[email protected] @[email protected] @[email protected] @[email protected]

Now we are getting into details...

Yes, everything directly related to some kind of unique global identifier is unlikely to be changed during the lifetime of an object.

Fields, that are describing an object, are more likely to be changed, but usually also not every some seconds.

In case of updating an actor regarding its description, the instance should send out an update activity for the actor object.

Also it should be considered, that remote instances will (or can) every now and then refresh their database and access other instances.

But i assume, you're not expecting thousands of instance servers world-wide to request your instance all the time...