Does not federate with Pleroma
clacke opened this issue · comments
Details: https://pleroma.soykaf.com/notice/9863320
In short, it seems that it won't post to their inboxes, because it expects the inbox attribute to be on the object rather than on the actor.
And the others cannot fetch the object, I'm guessing because the object has no URL and they won't accept the Create activity as URL for the object.
@clacke Just merged #8 that got past one issue, but discovered another.
It looks might this be because pleroma requires clients POSTing to its inboxes to do linked data signatures (distbin doesnt). Is that right? If so, why not make it optional? I could be missing something.
debug: [distbin.activitypub] ldn notify res 500 https://pleroma.soykaf.com/users/notclacke/inbox # MatchError at POST /users/notclacke/inbox
Exception:
** (MatchError) no match of right hand
debug: [distbin.activitypub] finished targetAndDeliver failures=[name=DeliveryErrorResponse], deliveries=[]
debug: [distbin.activitypub] failures delivering DeliveryErrorResponse: 500 response from https://pleroma.soykaf.com/users/notclacke/inbox
Response Body:
# MatchError at POST /users/notclacke/inbox
Exception:
** (MatchError) no match of right hand side value: []
(pleroma) lib/pleroma/plugs/http_signature.ex:18: Pleroma.Web.Plugs.HTTPSignaturePlug.call/2
(pleroma) lib/pleroma/web/router.ex:286: Pleroma.Web.Router.activitypub/2
(pleroma) lib/pleroma/web/router.ex:1: anonymous fn/1 in Pleroma.Web.Router.__match_route__/4
(phoenix) lib/phoenix/router.ex:273: Phoenix.Router.__call__/1
(pleroma) lib/pleroma/web/endpoint.ex:1: Pleroma.Web.Endpoint.plug_builder_call/2
(pleroma) lib/plug/debugger.ex:102: Pleroma.Web.Endpoint."call (overridable 3)"/2
(pleroma) lib/pleroma/web/endpoint.ex:1: Pleroma.Web.Endpoint.call/2
(plug) lib/plug/adapters/cowboy/handler.ex:16: Plug.Adapters.Cowboy.Handler.upgrade/4
## Connection details
### Params
%{"@context" => "https://www.w3.org/ns/activitystreams", "cc" => ["https://www.w3.org/ns/activitystreams#Public", "https://pleroma.soykaf.com/objects/57116435-1edd-4a3a-9d50-6df6eafe7398"], "http://www.w3.org/2002/07/owl#sameAs" => ["urn:uuid:72996466-6ac8-4448-9940-7e1bb55f67b4"], "id" => "http://localhost:8000/activities/72996466-6ac8-4448-9940-7e1bb55f67b4", "inbox" => ["http://localhost:8000/activitypub/inbox"], "nickname" => "notclacke", "object" => %{"content" => "Hi", "generator" => %{"name" => "distbin-html", "type" => "Application", "url" => "http://localhost:8000"}, "id" => "urn:uuid:f5e99154-294c-4db0-8c1c-b66362eed5f0", "inReplyTo" => "https://pleroma.soykaf.com/objects/57116435-1edd-4a3a-9d50-6df6eafe7398", "type" => "Note"}, "published" => "2018-06-07T08:10:35.309Z", "replies" => "http://localhost:8000/activities/72996466-6ac8-4448-9940-7e1bb55f67b4/replies", "type" => "Create", "url" => ["http://localhost:8000/activities/72996466-6ac8-4448-9940-7e1bb55f67b4"], "uuid" => "72996466-6ac8-4448-9940-7e1bb55f67b4"}
### Request info
* URI: http://pleroma.soykaf.com:80/users/notclacke/inbox
* Query string:
* Peer: 127.0.0.1:33816
### Headers
* connection: upgrade
* content-length: 935
* content-type: application/ld+json; profile="https://www.w3.org/ns/activitystreams"
* host: pleroma.soykaf.com
### Session
%{}
at /mnt/c/Users/bengo/dev/distbin/dist/src/activitypub.js:300:19
at Generator.next (<anonymous>)
at fulfilled (/mnt/c/Users/bengo/dev/distbin/dist/src/activitypub.js:4:58)
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:188:7)
I'm surprised, but it sounds plausible. IIRC the spec just says "[you should probably do some kind of sigs here]" and Mastodon chose LD sigs.
I think the spec recommends that in the absence of sigs you should verify content by re-reading it from the source, and I don't know if Pleroma tries that or not, but as I also failed to search and on-demand fetch distbin posts from Pleroma, it's possible that it tries to fetch the post for verification, but fails.
I'll ask on #pleroma (freenode) how Pleroma is supposed to act.
We don't use ld sigs, but we do require http sigs.
Some issues I see with the data in that request:
- No actor
- Sent from localhost (we can never fetch the sig or the user, even if there was an actor)
- Non-https object id (not dereferencable)
- Object id in cc (why? Objects don't have inboxes)
Thanks for dropping by. I had forgotten about the LD vs HTTP sigs, as I haven't actually done any implementation work. And I never would have thought of the other bits either.
An AP in practice guide by Somebody is sorely needed.
It needs to close the holes in the AP spec (the APS). Let's call it the AP Fediverse profile (the AFP) -- how the AP spec is modified and used in practice to federate with Mastodon.
- Where the APS says sigs would probably be a good idea, The APF needs to say that you need HTTP sigs to post anything, and you need LD sigs for whatever Mastodon needs them for (I don't know. Fat reposts? Reposts of non-public messages?).
- The APS carefully avoids saying you should handle acct: user references. The APF needs to say you need to handle them, you need WebFinger to handle them, and you need WebFinger as described in the RFC, not as described in Draft 2.
- The APS says you mustn't send out Block activities. The APF needs to say Mastodon sends them, and its users will be upset if you don't honor them and have the receiver unfollow the sender.
- Guidance on how to handle the sensitive attribute in the UI
- Guidance on how to handle CWs in the UI
I have only third-hand knowledge of all this, but if you do want to gift the world with this guide, simply documenting what you need to do beyond the APS to get Pleroma and Mastodon federation going would be a very good and sorely needed basis.