Further simplifying the spec by replacing aliases property with gateway (or should it be gateways?). The first gateway in the list is used to create MastoPub compatible URLs.
Gateways will probably be used to retrieve media as well:
I added some basic #activitypub support to humungus based on the #forgefed vocabulary. Repository, Commit, etc. And of course updated #honk as well. So now you can follow the honk repo from within honk itself and see all the commits fly by. Still a work in progress, but it’s live now. Probably do a longer write up next week.
- Full text search. The search query needs to be prefixed with ">". Only shows posts created by the current user. - Loading latest posts from other servers (this feature is currently only available to users with 'admin' role).
- Emoji picker in post editor (for custom emojis). - Subscription access without payment. Subscriber status can now be given as a gift, or in exchange for off-site payment (in any currency). To do this, navigate to any profile page and click on "Subscriber details" item in profile menu.
FEP-ae97 and FEP-ef61 require embedding signed objects into other signed objects (example: Create activity), but Data Integrity specification doesn't say how to do that correctly.
Looks like we have two options:
1. Use RDF canonicalization instead of JCS, double down on JSON-LD and RDF 2. Use JCS, but break compatibility with some JSON-LD processors
FEP-ae97 and FEP-ef61 require embedding signed objects into other signed objects (example: Create activity), but Data Integrity specification doesn't say how to do that correctly.
>When Threads blocks communication with other servers on the fediverse >...fails to meet our Community Guidelines... >We’ll also block a server if it doesn’t have a: >Sufficient privacy policy; or >Publicly available policy to restrict access to users under the age of 13; or >Publicly accessible feed
There are two fediverses. One of them will comply with these rules, and with whatever rules come after that.
>When Threads blocks communication with other servers on the fediverse >...fails to meet our Community Guidelines... >We’ll also block a server if it doesn’t have a: >Sufficient privacy policy; or >Publicly available policy to restrict access to users under the age of 13; or >Publicly accessible feed
The major downside of resolver-URL-as-ID is that existing actors can't be easily upgraded because of ID change, and migration via Move activity will be required. It is a one-time migration, and your actor will be forever free from the server of origin, so maybe it's worth it.
Another thing to note is that inbox is distributed too (its path is relative to DID-based actor ID). Initially I thought that clients will use resolver to get server-local HTTPS URL of an inbox (see section Dereferencing DID URLs, paragraph about the Link header). But now I'm wondering: why not make POST requests directly to the resolver?
Instead of being read-only, it can be read-write. So it's not really a resolver anymore, but maybe a gateway
The major downside of resolver-URL-as-ID is that existing actors can't be easily upgraded because of ID change, and migration via Moveactivity will be required. It is a one-time migration, and your actor will be forever free from the server of origin, so maybe it's worth it.