@hellekin Thanks for the report. A certain amount of failed requests will always occur on an ActivityPub service as actors in the fediverse come and go. For example, it looks like
The verbosity of the logs are there to help debug, however if they’re cluttering your logs you can toggle them using the site setting activity pub verbose logging. The default is off.
We will be looking to make error handling improvements in phase two if necessary, but so far it looks like the snippets you posted are expected, i.e. the Actors are indeed no longer in the fediverse.
Currently, the way the plugin handles delivery failures is to track them in the same way Mastodon does, namely, if there are 7 days of failure to an endpoint it will be marked as “unavailable” and requests will no longer be attempted.
I just setup a brand new self-hosted discourse with your AP plugin over at https://federation.cafe, and am seeing some 403 errors in the Discourse Error Logs (and the posts aren’t sharing).
I’m wondering if it might be because there are hyphens maybe?
[Discourse Activity Pub] GET request to https://bofh.social/internal/fetch failed: Expected([200, 201, 202, 301, 302, 307, 308]) <=> Actual(403 Forbidden)
The MVP plugin is tested against Mastodon. I see you’re using Pleroma there. I know Pleroma is ActivityPub compliant and works with Mastodon, however we haven’t looked closely at what tweaks might be required (if any) to ensure support for it yet. But still interested to see what’s going on here.
It looks like the requests failed due to an authentication error on your Pleroma server (that’s what a 403 error means). As I’m able to GET that endpoint just using an unauthenticated cURL request I suspect it might be the http auth that’s failing on the Pleroma end.
To test the latter (i.e. 2), could you have a look at your Pleroma logs (it looks like you’re the admin on that server too?) if possible to see if you can get more detail on that end of things?
Thanks for the feedback @bmann. Could you expand on the use case you have in mind here? With an example if possible.
This topic is the best place to keep abreast of developments. When we settle on a phase 2 plan I’ll share it here. In the meantime, the best way to help is to share specific use cases you are using, or would like to use, the plugin for.
The use case is using Discourse as a fuller AP node. There are many easier ways to post content to AP (eg use category RSS feeds and Zapier or Buffer) — but developing fuller AP capability can only be done as a plugin/integration.
Article is the ActivityStream type that is meant for full articles. Depending on the client interface, it will show a preview and then a click through to show the entire article inline (much like content warnings, but read more).
Note is the micro-blogging type.
By having full Article posts, people can directly read / boost / reply in their AP clients.
And of course, it would be interesting to hear about your roadmap if you’re going to follow a more Microblogging AP instance, or go in a federated forum direction like Lemmy or Kbin, especially given the recent Reddit news.
@angus, @pmusaraj have you seen NGI Sargasso funding open call? This is quite short notice but it might be useful to further development on this plugin (unless you have other plans already).
Hey guys, I’m happy to say that the second phase of work on this plugin has been approved. This is what we’ve already started work on, with the aim of releasing it in about 3.5 months.
Support Discourse users verifying their identity on Mastodon so Discourse posts created from their Toots are associated with their Discourse user account.
Allow a user to perform the Mastodon OAuth Authorization flow with the Mastodon server where their account is stored. This is initiated from the user’s Discourse account settings.
Using the Discourse user’s Mastodon access token, obtain and store the AP ID of their Mastodon account and store it with their Discourse account.
Associate all Discourse activities associated with AP Activities from an Actor bearing a Discourse user’s AP ID with that Discourse user, whether they were performed before or after the user verified their identity.
That’s a known limitation. Until federating edits is supported, the plugin blocks edits to federated content, and there is no configuration to disable this.
Oh, I’m sorry to have misunderstood. @feature@meta.discourse.org and @announcements@meta.discourse.org at least are being federated from here, and this choice is the number one reason I haven’t enabled this for Maker Forums…
