Embed Notice

@mikedev I can spot several differences between this document and the latest revision of FEP-ef61:

- FEP-ef61 now uses gateways property, not gateway. I changed the property name because its value is an ordered list (and we already have replies and orderedItems, so a plural doesn't feel inappropriate).
- Canonical object ID has no path component. FEP-ef61 says that path is REQUIRED (according to RFC 3986, the path can be "empty", so I should probably change it to "path MUST NOT be empty").
- The value of proof.verificationMethod is a "compatible" ID, but according to FEP-ef61, "The value of verificationMethod property of the proof MUST match the authority component of the ap:// URL". In other words, it must be a DID.

Of course, all of that is up to discussion, and the spec can be changed if necessary.

>The sticky spots I see right now are abstracting a more portable url for profile-photo, cover-photo

We can use content-addressing. See Discussion / Media section.

>and ed25519 publickey

I assume you're referring to the need for it to be a server-owned key? Per FEP-521a we can add multiple keys to assertionMethod array. Each nomadic clone can use its own key for signing HTTP requests, only the identity key (the "authority" part of 'ap' URL) must be shared.

>You should be able to import the resulting record into any FEP-ef61 compliant server running on any fediverse platform and have one identity to rule them all.

In my implementation exported objects and the ones sent via S2S protocol will probably look the same, because in the future I will perform proof generation on the client side. This means the server will not be able to change published objects, its role will be merely of an indexer.