Can't Follow from pubgate

[mrvdb]

I'm not sure if this is a bug in writefreely or pubgate, but I get info in the logs of writefreely, so I'll start by posting here and ping @autogestion on it.

Example: I'm trying to follow 'https://qua.name/mrb' from an instance of https://github.com/autogestion/pubgate

The actor there is: https://activitypubbot.qua.name/ap_bot

May 02 17:47:21 shout writefreely[491]: 2019/05/02 17:47:21 "GET /mrb" 301 3.580406ms "PubGate v:0.2.12"
May 02 17:47:21 shout writefreely[491]: 2019/05/02 17:47:21 "GET /mrb/" 200 2.316582ms "PubGate v:0.2.12"
May 02 17:47:21 shout writefreely[491]: 2019/05/02 17:47:21 Fetching actor https://activitypubbot.qua.name/ap_bot locally
May 02 17:47:21 shout writefreely[491]: 2019/05/02 17:47:21 Not found; fetching actor https://activitypubbot.qua.name/ap_bot remotely
May 02 17:47:21 shout writefreely[491]: 2019/05/02 17:47:21 GET https://activitypubbot.qua.name/ap_bot
May 02 17:47:21 shout writefreely[491]: ERROR: 2019/05/02 17:47:21 log.go:26: Unable to unmarshal actor! json: cannot unmarshal stringGo struct field Person.@context of type []interface {}
May 02 17:47:21 shout writefreely[491]: ERROR: 2019/05/02 17:47:21 log.go:26: Unable to resolve Follow: Couldn't parse actor.

• the user ap_bot is of type 'Service' but switching it to 'Person' makes no difference.

[autogestion]

Looks like (I'm not familiar with Go) that writefreely expect that @context field should be list, and it is string
https://pubgate.autogestion.org/dev

[thebaer]

Yep, that must be it. Thanks for the report, and the input!

[mrvdb]

Is there anything I can do to help? This sounds like an issue in the upstream library rather than in writefreely directly, but I haven't actually dived in.

[thebaer]

I believe we need to change the type of Context from []interface{} to interface{} here in the web-core library, and then make any adjustments in WF needed with that change.

[mrvdb]

That indeed sounds like a good start

I seem to recall seeing different manifestations of the @context field reading some W3 documents with some examples of it, that is, it also seems to occur as an array sometimes, but I may be mistaking it for something else.

[thebaer]

Right, it does occur as an array, especially with platforms like Mastodon. But changing the type to a plain interface{} will let us handle either case

[ghost]

That indeed sounds like a good start

I seem to recall seeing different manifestations of the @context field reading some W3 documents with some examples of it, that is, it also seems to occur as an array sometimes, but I may be mistaking it for something else.

indeed, 3 possibilities: https://www.w3.org/TR/activitystreams-core/#jsonld

[ghost]

This is getting interesting.

If there are three acceptable data structures to represent an activity context, I think if the web-core returns the list style we can make any changes needed here in writefreely.

So maybe creating a named type for our web-core Context and using that, with an empty map when no additional terms are to be included.

[ghost]

it's interesting too that there was a change in pubgate less than a month ago that fixed some issue with following, the change included going from a list of context values to a single string.

autogestion/pubgate@c93945c#diff-ca148059ba63a1a73f527921dea53dc2

It would be nice to hear from @autogestion about this change as well.

[autogestion]

@robjloranger
when I started implementing pubgate, I just copied @context from mastodon object. Then I used to know that in fact it is way to extend AP objects with new attributes. I didn't used that extensions, but decided to leave as it is, to not break compatibility. When I was fixing following, I noticed that in mastodon's Follow object @context is a string (in mastodon user profile it's a list), and decided to strip pubgate's context from useless elements)

[ghost]

cool, thanks for the clarification @autogestion 💚

[autogestion]

Meanwhile, do you use data extracted from @context in some way? If not, you can just skip parsing this attribute

[thebaer]

We don't use the data right now, but since the field is there in the struct (for when we use it to send out ActivityStreams data), Go will try to parse it. I'm sure we could override this behavior, but I don't think that'd be the route to go.