Interopability With The Wider Fediverse

[ghost]

Is there any interest in adding sufficient features to allow other AP software to play nice with FChannel? Ted Unangst's blog post "ActivityPub as it has been understood" is a good primer but from glancing through the Fchannel code it looks like the only things that would be needed are an endpoint to fetch the actor object and webfinger.

[ghost]

I see now that I was just using the API wrong and that there isn't much to be done from FChannel's side if other software wants to interop since the actor is a service-type actor.

I will leave this open to ask if there is any interest in a patch for webfinger support since actor@instance is a pretty standard way to refer to things in AP.

[FChannel0]

Hello,
Yes its pretty simple atm to retrieve the boards information. Make a get http request to the actors outbox with the correct activitypub content-type and you get an ordered list of posts and their replies in activity+json standards.
GETing is easy, POSTing to a board is only guaranteed when running a FChannel instance. I have to look at other projects for processing posts and what they send for their activity streams. FChannel is going about it in simple way that has to be updated though to be more robust as other fedi platforms atleast with activity communication standards access points and stuff. I see a lot using /api/v1/user/something FChannel is just fchan.xyz/g/outbox or fchan.xyz/g to get the actors information

[ghost]

I think the question (aside from webfinger support) is more about how fchannel wants to handle messages from non-fchannel implementations. In most fedi software, an AP actor maps to a user, not a board. Fchannel will have to decide how to handle actors with the person type if you want to be interoperable.

[lanodan]

For pleroma we're sending application/activity+json into the Accept header, and from quickly going through main.go, I think you're not handling cases like Accept: application/activity+json, application/ld+json.

The /api/ stuff definitely isn't related to ActivityPub btw. You're probably refering to Mastodon API, which doesn't makes any sense for FChannel to use.

[FChannel0]

Hello, Ianodan it should be able to process both types of header Accept, but current FChannel is only using application/activity+json I needed to add a condition for application/activity+json, application/ld+json
also I was looking over the api for pleroma, where would I send an activity stream to an actor.
Say @Someone@pleroma who was in a post quote and I want to send them the Note they are apart of? Would it be a POST request to /api/v1/user/...../statuses? found it from here, but still a little vague https://docs-develop.pleroma.social/backend/development/API/pleroma_api/ I guess where is their inbox/outbox

[lanodan]

I needed to add a condition for application/activity+json, application/ld+json

You need to have it parsed, Go probably has librairies for this otherwise look into the RFCs but consider grabbing existing code.

I was looking over the api for pleroma, where would I send an activity stream to an actor.
Say @Someone@pleroma who was in a post quote and I want to send them the Note they are apart of? Would it be a POST request to /api/v1/user/...../statuses? found it from here, but still a little vague https://docs-develop.pleroma.social/backend/development/API/pleroma_api/

Please, just forget about any /api/, it is for clients, FChannel is a server.

The ~only relevant documentation for you is the Server-to-Server part at: https://www.w3.org/TR/activitypub/#outbox-delivery

I guess where is their inbox/outbox

Yes, your software grabs the urls in inbox or sharedInbox on the relevant actors, removes duplicates and pushes it to everyone.

[FChannel0]

The ~only relevant documentation for you is the Server-to-Server part at: https://www.w3.org/TR/activitypub/#outbox-delivery

Ok thank you, that clears it up. Wasn't sure if other fedi servers such as Pleroma took different paths. I can discover the actors correct routes then.

[153]

I think that Lemmy would be a better thing to target for thread imports ; pleroma/mastodon for importing replies to threads makes more sense than trying to build threads from pleroma/mastodon feeds. I would consider adding a mode where specific Pleroma conversation threads can be manually imported via web.

See also https://github.com/153/fedichan -- Futaba frontend for Mastodon. There is currently no live demo, but I can set one up if you'd like :)

[ghost]

Lemmy is a better target, I agree. I was going to start working on this like a month ago but as it turns out lemmy is a pain in the ass to set up even a dev environment so I never got around to it.