So looking at that spec… Nothing there is validation that current messages originate from an “original” server…
I don’t think either of these signature options for Server to Server communications means that my current lemmy.saik0.com instance can’t be torn down (delete LXC container) and reconfigured as a brand new instance (New LXC container) and other instances wouldn’t know that there’s been a change to the instance running here… or more accurately would flag a change. I think these signatures are all about not being able to spoof OTHER instances. eg, lemmy.ml can’t send messages on behalf of lemmy.world.
I assumed that once federated the public key would be remembered and signatures that do not match it would be handled, but you may be correct. I do wonder whether this could be a problem as instances close down over time. I’ll have to spend some more time researching to see if there’s a more clear answer, or if any ActivityPub implementations have their own way of handling that situation.
Yeah that’s my worry. I’m pretty sure(and could be wrong) that message/ keys are only checked on ingestion. So i would get key value for a message coming in and can check that is currently valid, not that it’s “changed” since 2 months back. I think this could allow for some one to ressurrect an old Lemmy service and masquerade as the old one… communities , users… all of it.
Can you show me documentation that shows communities or servers are signed?
https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization
So looking at that spec… Nothing there is validation that current messages originate from an “original” server…
I don’t think either of these signature options for Server to Server communications means that my current lemmy.saik0.com instance can’t be torn down (delete LXC container) and reconfigured as a brand new instance (New LXC container) and other instances wouldn’t know that there’s been a change to the instance running here… or more accurately would flag a change. I think these signatures are all about not being able to spoof OTHER instances. eg, lemmy.ml can’t send messages on behalf of lemmy.world.
I assumed that once federated the public key would be remembered and signatures that do not match it would be handled, but you may be correct. I do wonder whether this could be a problem as instances close down over time. I’ll have to spend some more time researching to see if there’s a more clear answer, or if any ActivityPub implementations have their own way of handling that situation.
Yeah that’s my worry. I’m pretty sure(and could be wrong) that message/ keys are only checked on ingestion. So i would get key value for a message coming in and can check that is currently valid, not that it’s “changed” since 2 months back. I think this could allow for some one to ressurrect an old Lemmy service and masquerade as the old one… communities , users… all of it.