Help needed with #pherephone development. Boosts not federating to pleroma

Software
1

#pherephone boost to pleroma Y U NO WORK??

This is a #pherephone “Announce” activity from a writefreely post. It works on mastodon but not on pleroma. I cannot understand why this is. Can any helpful #pleroma or #ActivityPub experts give a hint?

POST request to https://pleroma.site/users/qwazix/inbox succeeded (200): 200 OK 
Response: "ok" 
Request: {
        "@context": [
                "https://www.w3.org/ns/activitystreams"
        ],
        "actor": "https://floorb.qwazix.com/myAwesomeList5",
        "cc": [
                "https://pleroma.site/users/qwazix",
                "https://cybre.space/users/qwazix",
                "https://fosstodon.org/users/qwazix"
        ],
        "id": "https://floorb.qwazix.com/myAwesomeList5/item/ULeVhJOsBTqWN22v",
        "object": "https://mixt.qwazix.com/api/posts/mncqqz3y7u",
        "published": "2019-10-14T12:13:43+03:00",
        "to": "https://www.w3.org/ns/activitystreams#Public",
        "type": "Announce"
} 
Headers: 
    Accept: application/activity+json; charset=utf-8
    Accept-Charset: utf-8
    Content-Type: application/activity+json; charset=utf-8
    Date: Mon, 14 Oct 2019 09:13:44 GMT
    Digest: SHA-256=Cl3iznjWvGXEFev5OP6ChwvVtY/Xtaw43ahnhXh4d4A=
    Host: pleroma.site
    Signature: keyId="https://floorb.qwazix.com/myAwesomeList5#main-key",algorithm="rsa-sha256",headers="(request-target) date host digest",signature="fnPHBAqWCIr3EpbwllBwFxhKJ03c23+evwPfX+Bcf/CEenQ/ZgTCViK5Gs0fW8qjzGuSCkYpFKFt7rmEiuXg7T4RkUy2LWq+kfTq8t/jWeS2LUCxNXRAgyJfhH2kioYefKqx6gl414js0qdFk6I0WWvtXpGuKIuiF/WK9FPx7WpJFJfN1WZ2kEdi87F0gRIAjllaGST15ZMx0mFkLVks2Vdff6saPR+V83muGClfzh78AN2XR4fnYve9m5Wm4/U6Q8n503CE/yfBb5bZSmfJZXZSlErT6L224b8LWKC7Q+IHe17k+aFibl/dNAknjmQwm/xFOdNzVHwGWXyhSrchGw=="
    User-Agent: pherephone 0.99

EDIT: I also tried after reversing the cc and to fields just as pleroma does.

/home/qwazix/go/src/github.com/writeas/activityserve/actor.go:502: POST request to https://iscute.moe/users/qwazix/inbox succeeded (200): 200 OK 
Response: "ok" 
Request: {
        "@context": [
                "https://www.w3.org/ns/activitystreams"
        ],
        "actor": "https://floorb.qwazix.com/myAwesomeList5",
        "cc": "https://www.w3.org/ns/activitystreams#Public",
        "id": "https://floorb.qwazix.com/myAwesomeList5/item/EUyTQEnz1gJK3qu3",
        "object": "https://fosstodon.org/users/qwazix/statuses/102966679309503735",
        "published": "2019-10-15T16:40:40+03:00",
        "to": [
                "https://floorb.qwazix.com/myAwesomeList5/followers",
                "https://cybre.space/users/qwazix",
                "https://fosstodon.org/users/qwazix",
                "https://iscute.moe/users/qwazix",
                "https://pleroma.site/users/qwazix"
        ],
        "type": "Announce"
} 
Headers: Accept: application/activity+json; charset=utf-8
Accept-Charset: utf-8
Content-Type: application/activity+json; charset=utf-8
Date: Tue, 15 Oct 2019 13:40:41 GMT
Digest: SHA-256=U30KWCsixidktfC/JToZSCX9HXoysMNrTqLPPzf62LI=
Host: iscute.moe
Signature: keyId="https://floorb.qwazix.com/myAwesomeList5#main-key",algorithm="rsa-sha256",headers="(request-target) date host digest",signature="DONBUM3O3s/YU/B4F9pWPWgFx1P7ZruJbuTrDVYIdY6m2EpVI7yihy157o3aUoC37acKuoo9F+F0sbOHyt3B3lwe+3eWHq0WbVDfoeIdOIFGVo2s9BxK748RHSSVU0lnLsIOQ/A3B3rRkkLlJ1zc3kdfHzfaNzQPUQJ9SL72x55sgzIthIY+vSAbS/IHbup5XomenkHynsj33F9RCYPqXajPRMUXPx0ljFcfRyQGX7/opipDQ4V2ANzjLHwosnHvKss+DQK9e2ZBbq3PaKYUwmKWdwDCQfzEok+hz6xTGzCnw8K7yICu2c1YNU0PD+q5rCATWhNuA3vPeme1iTcZ5A=="
User-Agent: pherephone 0.99

The thing that bothers me the most is that I get an “ok” response and a 200 but the post never appears in the interface.

Reposted from my blog

2

I looked into it a bit after/during Prague ActivityPub Conference but I
forgot what was the issue since then.
I wanted to note that federation issues are mostly managed by submitting
a ticket to our bugtracker: https://git.pleroma.social/pleroma/pleroma

Luckily pleroma has a good presence on SocialHub, but I’m not sure if
having more places where one can submit federation issues with one
software is a good idea, would be great for software like Mobilizon
which needs to be interoperable with almost completely new activities
(friendica also does events over ActivityPub) on the fediverse.

2 Likes
3

I’m pretty sure it’s an issue on my end so I didn’t want to spam the issue tracker. I will leave it for another day here just in case someone sees something obvious and then I will bug you on the tracker (bad pun I know :stuck_out_tongue: )

Thanks

4

I don’t know whether that’s related but I noticed your Content-Type header is missing the profile attribute: according to spec 3.2 the server "MUST present the ActivityStreams object representation in response to application/ld+json; profile="https://www.w3.org/ns/activitystreams".

Maybe making this modification will help.

1 Like
5

Unfortunately it exhibits the exact same behavior both with application/ld+json; charset=utf-8; profile="https://www.w3.org/ns/activitystreams" and with application/activity+json; profile="https://www.w3.org/ns/activitystreams", but still I will keep the profile attribute. Thanks for pointing that out.

6

[2019-10-17 12:39:45+0000] qwazix via SocialHub:

Unfortunately it exhibits the exact same behavior both with application/ld+json; charset=utf-8; profile="https://www.w3.org/ns/activitystreams" and with application/activity+json; profile="https://www.w3.org/ns/activitystreams", but still I will keep the profile attribute. Thanks for pointing that out.

The profile attribute is only needed when using application/ld+json as application/activity+json implies ActivityStreams.

2 Likes
7

I tried registering with the gitlab instance on git.pleroma.social but I can’t seem to get the confirmation email. Any pointers?

EDIT: It just took its time. Sorry.

8

I tried looking into this, but I couldn’t resolve the actor https://floorb.qwazix.com/myAwesomeList5, it just timed out.

10

https://mixt.qwazix.com/api/posts/mncqqz3y7u has an invalid id:

$ curl -s -H 'Accept: application/activity+json' 'https://mixt.qwazix.com/api/posts/mncqqz3y7u' | jq .id
"/api/posts/mncqqz3y7u"

Pleroma will reject this object because the ID is not a proper URI.

(to clarify, it can be any proper URI, not just an http/https one. but it has to be a URI, not a relative path.)

11

@nightpool I’m sorry this is my working laptop instance. It’s up for now but I’ll try to set up a permanent one on a server asap.

@kaniini this is another bug (IIRC it’s already fixed in mainline, my blog is one version behind) on writefreely. The reblog however doesn’t work with mastodon id’s either (see second example)

12

This issue has been resolved: see issue

TL;DR: I needed to replace the To and Cc values with arrays.

Thanks to all.

1 Like
13

Resolved is relative here. @kaniini
Personally I would prefer if simple strings are accepted by pleroma.

See Section 6.1 of the spec. :
While it defines “who to address” the final result in cc is still a string and so
EXAMPLE 14 of the spec. (amongst others) would fail !

And just btw –
If anyone wants to test against the examples, find em all as a JSON in the /test/examples folder !
It is a simple array with [titleOfTheExample, example] …

14

I guess this is a fair view, and should not be too difficult to handle on Pleroma’s side: if it’s a string, wrap it into an Array, and you’re done.

I also noticed in the spec that most of the fields that often appear as strings in the examples can be arrays, so this approach could be generalized without requiring everyone to be stricter than the spec.

Do you have an issue about this in Pleroma, so we can reference it here to help following up?
At least other people bumping into this would effectively know the workaround (wrap everything into arrays) and eventually drop that constraint when the use-case is handled natively in Pleroma.

15

[2019-10-22 13:17:25+0000] hellekin via SocialHub:

I guess this is a fair view, and should not be too difficult to handle on Pleroma’s side: if it’s a string, wrap it into an Array, and you’re done.

I also noticed in the spec that most of the fields that often appear as strings in the examples can be arrays, so this approach could be generalized without requiring everyone to be stricter than the spec.

Do you have an issue about this in Pleroma, so we can reference it here to help following up?
At least other people bumping into this would effectively know the workaround (wrap everything into arrays) and eventually drop that constraint when the use-case is handled natively in Pleroma.

Putting everything into arrays naively isn’t going to work, doing it in a way similar to what is seen in the wild is more like it. We could try to handle everything that you could do in ActivityPub but that would be quite a nightmare because IIRC there is no type restriction other than the ones with a single static type in their JSON-LD definition. (not that much)

We did it in a “let’s support what we see in the wild” manner because everything legal in ActivityPub makes sense by itself (like favoriting an actor might make sense at some point but right now it doesn’t).

16

The single-value-ness of non-functional (I hate that term) ActivityStreams properties with a single value is go-fed’s serialization behavior, which is what WriteFreely uses. If there’s more than one value, then it will be a JSON array. Go-fed can handle deserializing both.

The reason why, is because what is in the wild is a convention of “some non-functional properties being single-values, others being arrays”, so go-fed attempts to do the intelligent thing when sending and widely accept what it receives.

1 Like
17

not sure I understand this point. is there anything technically blocking pleroma from being treating “single element” and “arrays of a single element” the same? by the JSON-LD spec, they’re identical.

18

Pleroma’s ActivityStreams code can handle deserializing string to and cc just fine.

This is likely related to spam protection on user inboxes (which happens before deserialization), actually.

It will be corrected, there is no need to tell us to fix it.

19

Pleroma actually handles serializing and deserializing this just fine, it is just a problem with certain pre-flight checks that are done on user inboxes (namely, we peek at the activity to see if the user inbox matches one of the addressees).

20

I added explicit regression tests in commit 2777aea45b which shows that Pleroma can handle to and cc single-value messages just fine.

As I mentioned, this is related to a spam protection we have on user inboxes. That will be fixed, but asking somebody to use arrays (as it is something I know we have had issues with before) and see if it works does not mean that we do not consider it a bug. I do not appreciate this blowing up into something that it did not need to be.

As for JSON-LD safety in Pleroma, the main area of weakness has to do with the fact that protocol modules are responsible for demarshalling data to Pleroma’s IR and committing the side effects at the same time, which leads to people occasionally messing up and assuming that their code is running in an IR-safe context when they are actually processing JSON-LD. I could write a very long-winded explanation about what Pleroma IR is, but a simple explanation is that Pleroma IR is a very strict subset of JSON-LD that is optimized for how we store our view of the distributed graph in our database.

The plan is to split side effect committal and IR into two phases. CommonsPub did something similar in their fork, but I don’t particularly like the approach there. And of course, they moved away from storing the activities as graphs altogether.

1 Like
21

this is true, however I re-wrote pherephone without go-fed as it the interfaces it requires were too much of an overkill for it. The running instance @pherephone.print3d.social still uses go-fed but the one that presented this problem does not.

1 Like