@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.
I canāt make any promises at this stage but there may well be intermediate updates for both Update federation and Audience Targeting (public posting).
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ā¦
Yes, this is the first item in Phase 2 that Iāve worked on. In fact, thereās already a PR for it, so youāll get some relief on that front soonish.