NodeBB-ActivityPub Bridge Test Instance

@ariadne@social.treehouse.systems right. I think functionally I'll never encounter a Delete, check the origin, and find that the note hasn't actually been deleted, but stranger things have happened!

Hi @Jay-Moonah just mentioning you in this topic

@unexpectedteapot Thank you. Indeed I missed that distinction, sorry for the noise @hongminhee.

@julian that's a good point. I feel it'd mostly be better for integration with Lemmy/Kbin type systems that mimic forums.

Of course you have a wiki page for this already! Why am I not surprised. Yes, that follow-accept has state synchronization responsibilities means that some additional specification would be nice, though as long as everybody tends to conform to the same behaviour I suppose thats less urgent. I still don't like that the current UX is "follow is in a pending state", but short of additional specification re: error handling, there's not much to do here. At any rate it seems I am now correctly following @weekinfediverse@mitra.social so I suppose maybe my server was slow at processing the accept.

test reply from another account

AT Protocol by Bluesky offers Portable accounts (Change hosts without losing your content, your follows, or your identity) so it will end up in exporting profile at /user/yourusername/consent and using it elsewhere.

That failed. Trying again.

Interesting. I received a repeat notification from @ActivityPub on my last comment. I suppose that is how you are acknowledging that my post was sent to people following that category. I like it.

@trwnh@socialhub.activitypub.rocks said in Handling "410 Gone" when retrieving an actor: You could do what Reddit does and just leave the posts up but pointing to a tombstone user. If you've ever seen a post attributed to [deleted] then you know what I'm talking about. Yes, this makes sense. It's coming into clearer focus why account and content deletions are so noisy in ActivityPub, since each deletion of a user's content needs to be federated before the account can be deleted. In absence of anything more explicit (like your aforementioned DeleteAllCreatedObjects), that's all we have to explicitly signal full account and content deletion. I think we'll go ahead with that. NodeBB already does display something like [deleted] (we show "A Former User"), and we also save the old user id as a reference in case it needs to be cleaned up. That'll work, thank you for your input a!

@baris said in Here's a test topic: Another test reply Very nice!

yipes, let's hope those explosions don't continue

@julian @thisismissem which is to say, the following are equivalent within the same scope...@\context: [{toot: http://joinmastodon.org/ns#,Emoji: toot:Emoji},{toot: http://joinmastodon.org/ns#,IdentityProof: toot:IdentityProof}]@\context: [{toot: http://joinmastodon.org/ns#,Emoji: toot:Emoji,IdentityProof: toot:IdentityProof}]

@julian to clarify: this is mostly about "canonical" identifiers vs. aliases. there is generally one canonical identifier for the conversation collection, and this is what should be used as the value of `context`. this could get a bit complicated but there are potential ways to coordinate replication between equivalent conversation collections, probably involving mutual following/follower relationship, plus some indicator of aliases like `alsoKnownAs` or some other extension property.

And yes, it works! It's certainly unintuitive but that's fair enough for a work in progress! It doesn't appear in the recent posts for that category (it was an empty category and still says "no new posts"), but that's a minor detail.

https://x.com/MiamiDolphins/status/1854589009709904292

julian: If the activity is the thing being forwarded, then an additional complication could arise in that I cannot simply re-sign the activity, as my instance key does not belong to the originating actor. this is indeed an issue that arises due to the following: ActivityPub does not specify any authentication/verification mechanism HTTP Signatures, which the current fediverse uses, are not replayable or relayable. If you're concluding that this makes inbox forwarding impossible with HTTP Signatures, then congratulations, you understand why LD Signatures ended up being used for this (and why FEP-8b32 proposes using Data Integrity Proofs at the LD level as well). It's either that, or find a way to replay entire HTTP messages (so that the HTTP Signature can be validated against the original HTTP interaction). Or otherwise rethink the fundamentals of the fediverse's entire security model.

@julian Yes, IDs should be unique:>All Objects in [ActivityStreams] should have unique global identifiers. ActivityPub extends this requirement; all objects distributed by the ActivityPub protocol MUST have unique global identifiers, unless they are intentionally transient-- https://www.w3.org/TR/activitypub/#obj-id

Here's another reply for @Claire@social.sitedethib.com, but with the replies property sending null instead of []. cc @devnull@crag.social

@julian @BeAware if by not advisable you mean not possible, yeah.You won’t be able to reuse the domain/subdomain later on if you take down your instance unless you have a self destruct function. And even then -every- server you’ve federated with has to be contacted for it to work correctly.It’s fun