Mauve 👁💜 @mauve@mastodon.mauve.moe

@aynish @cblgh yeah that seems to be the case. Dunno if I want to go through the effort of setting uo an entire instance for the odd one on one call though 😅

@thisismissem That's not the case I meant to refer to. The assumption is that all servers you've communicatd with have a cache of the actor already which is not something in the spec and therefore can break depending on the implementation.

@thisismissem Yeah, it's just that that assumption isn't part of the spec. 🤷 Probs just an edge case that will happen sometimes that folks don't need to worry too hard about I guess.

@thisismissem By fetching the actor data from their url instead of cache. For example what if you send the update but the server doesn't have your old actor cached already.

@thisismissem Interesting. So they sign it with the old key instead of the new one? That'll cause some errors for my current setup. 🤔

@thisismissem @joelving Oh one last bit with ActivityPub in particular, you can send an Update activity to people's inboxes which can enable even more aggressive caching while still being able to invalidate the cache when needed.

@thisismissem @joelving Every ActivityPub implementation needs to do some variation on this sadly.

@thisismissem @joelving Yup! Tradeoffs

@thisismissem @joelving At the moment I'm using HTTP caching mechanisms (E.G. ETAG) to reduce how much data is being re-fetched. So it's a bit better than a one time MITM being able to poison the cache forever and a bit better than fetching for each authentication.