#mainkey — Public Fediverse posts

yeah something that people seem not to realize... the $INSTANCE$HOST stuff is specifically just modified software. It relies on an instance having signed requests enabled. When your instance receives the activity it fetches the object. The remote instance in question then needs to verify your key (usually, it stores your public key for a bit but sometimes not.). In the case of misskey I am pretty sure that the key in question corresponds to @instance.actor so what happens is a GET https://transfem.social/users/9hx2fp1ek3vwhd57 (sometimes they do #main-key sometimes not). the modified instance code then replaces the content of the post dependent on the host of the signing key. so you never end up actually seeing the text $INSTANCE$HOST because that's just a variable for the modified code to replace.

yeah something that people seem not to realize... the $INSTANCE$HOST stuff is specifically just modified software. It relies on an instance having signed requests enabled. When your instance receives the activity it fetches the object. The remote instance in question then needs to verify your key (usually, it stores your public key for a bit but sometimes not.). In the case of misskey I am pretty sure that the key in question corresponds to @instance.actor so what happens is a GET https://transfem.social/users/9hx2fp1ek3vwhd57 (sometimes they do #main-key sometimes not). the modified instance code then replaces the content of the post dependent on the host of the signing key. so you never end up actually seeing the text $INSTANCE$HOST because that's just a variable for the modified code to replace.

@[email protected] Strongly agree because I think that some people's concerns can be taken care of. https://github.com/jointakahe/takahe (considering how takahe allows for multiple domains) in combination with some other factors I have discussed. If people want to continue using the "instance" model they have built up, it's entirely conceivable to have actors referred to on an instance's domain with the custom domain actually just pointing to the same object. This way if someone exists on http://custom.example.local but actually belongs to http://example.local/ when they fetch something for instance it uses the signing key at http://example.local/users/${id}#main-key (of course, I am interested in this because I quite like how bluesky lets you do custom domains and subdomains.)

@[email protected] Strongly agree because I think that some people's concerns can be taken care of. https://github.com/jointakahe/takahe (considering how takahe allows for multiple domains) in combination with some other factors I have discussed. If people want to continue using the "instance" model they have built up, it's entirely conceivable to have actors referred to on an instance's domain with the custom domain actually just pointing to the same object. This way if someone exists on http://custom.example.local but actually belongs to http://example.local/ when they fetch something for instance it uses the signing key at http://example.local/users/${id}#main-key (of course, I am interested in this because I quite like how bluesky lets you do custom domains and subdomains.)