Open rocky-III opened 2 years ago
Rocky or anybody else reading this - do you have a link to one of these activities? I'd be glad to throw it in my dev environment and see if I can figure out if there is something on our end that is tripping it up and/or provide some technical detail to the inventaire folks if it isn't something we can handle.
Thanks - that works just fine in (streams). There was an initial issue with fetching the URL from a navbar search as we had sanitised the input and this escaped the & in the url. That's now fixed so search works and it loads fine from the dev tools and parses into a valid message. So beyond fixing the navbar search to handle ampersands I don't see any federation problems here.
I would strongly recommend that the inventaire folks use the long form of the ActivityPub public inbox url and make the 'to' field an array in all cases, even if it only has one recipient. While we can parse that just fine and it's entirely legal, I know of a number of projects which will probably fail on that construct - and I highly suspect that Hubzilla is one of them. One could insist that this usage is correct (and it is); and request that other projects fix their code - however my experience with this approach is that unless it breaks Mastodon it is highly unlikely it will get fixed any time soon.
Thank you for your time above, i do think the problem is on inventaire side, though. After some investigation, setting up a peertube instance (which worked like a charm for testing purpose in a docker env). The error thrown looks like:
peertube_1 | 2022-11-06 20:39:40.504 error: Client log: No subscribe template in webfinger response
Thanks to this explicit error message, we can trace back the error to this.
Webfinger spec does not mention any template
key. I couldnt find any documentation on why services needs this template key to be implemented.
Looks like pleroma needs it too.
The webfinger response inventaire sends should then look like (?):
const actorUrl = makeUrl({ params: { action: 'actor', name } })
const templateUrl = makeUrl({ params: { action: 'actor', name: "{uri}" } })
return {
subject: `acct:${name}@${publicHost}`,
aliases: [ actorUrl ],
links: [
{
rel: 'self',
type: 'application/activity+json',
href: actorUrl
},
{
rel: 'http://ostatus.org/schema/1.0/subscribe',
template: templateUrl
}
]
This empirical suggestion leave me a bit troubled on where i can find some documentation on this webfinger spec, required by a lot of fediverse services (but not mastodon) that could confirm this truth.
Some may say its for remote follow interaction. Others talk of having a UI to follow users from another instance.
All we need for now is the same interaction (which works on mastodon): looking for a actor and following them. If any fediverse instance admin (except masto or peertube) could send us some logs of a user search such as demo user @Georges@inventaire.io, would be very nice, otherwise ill continue setting up test other test instance.
As we have been primarily integrating with Mastodon's flavor of Activitypub, that page can be interesting to see the protocol extensions used by Mastodon https://docs.joinmastodon.org/spec/activitypub/#extensions . I'm not really in the context, but from a quick look, the following extensions could be relevant: Public Key (HTTPS Signatures), Profile metadata (attachment
)
@jum-s and I had a look at the problem, and might have found its source: the activities were sent with an application/json
content type. This has now been replaced by application/activity+json
(18bc1ad4 and 32b8bc3e1). @rocky-III can you retry the test with Stream?
@maxlath NO - seams not to make a difference for Hubzilla and streams :-(
Federation does not work with other apps besides Mastodon. This is sad because the Fediverse consists out of many others apps.
I did a test with Hubilla, Zap and Streams like a main Dev told me to do:
and it seams that there is an issue with inventaire. Could you please have a look. THANKS a LOT and thanks for your great application.