@[email protected] @[email protected]

Afaik currently #BlueSky runs the one and only relais. So currently they run the one and only #atproto relais.

That's the current situation. May change in the future. May not.

@[email protected] @[email protected]

Yes, afaik currently #BlueSky is developing #atproto. And is also the only one, that operates a relais.

#ActivityPub is an official #W3C recommendation (January 2018). Several implementations exists, not only #Mastodon.

Huge difference.

@[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...

@[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!?!

@[email protected] @[email protected]

#Webfinger should return the right result.

Currently one of the given addresses results in a 404.

And the other one looks very short...

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

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?

@[email protected]

Interesting.

How do you use the #Mastodon client #API?

Do you test the compatibility of other implementations as well?

How do you decide which #Fediverse server type to count in? Besides Mastodon (of course) you mentioned #WordPress with #ActivityPub.

What about others, e.g. #Friendica.

And yes, i wrote this post using #Tusky on a #Mammuthus instance via my own implementation of the mentioned API.

A nice weekend and thanks for your work.