"The reason that ATProto and ActivityPub developers don't collaborate is that ActivityPub developers are rude."
-
@evan A poll would be irrelevant, it should be asked to the ATproto developers
-
@evan differnt AP platforms don't really collaborate.
I doubt rudness is a factor, you seem nice
lol -
@evan A poll would be irrelevant, it should be asked to the ATproto developers
@liilliil Why's that?
-
@liilliil Why's that?
@evan Because on our end, the result will be predictable
-
@evan Because on our end, the result will be predictable
@liilliil you should definitely run that poll, then.
-
@evan differnt AP platforms don't really collaborate.
I doubt rudness is a factor, you seem nice
lol@ozzy Thank you!
-
undefined Evan Prodromou ha condiviso questa discussione
-
@evan seems like this particular poll might be just slightly biased
-
@bkardell how so?
-
Thanks to everyone who replied. I agree with the vast majority on this.
-
Thanks to everyone who replied. I agree with the vast majority on this.
There are many opportunities for ActivityPub and ATProto developers and operators to collaborate: at standards bodies like IETF and W3C, in conferences, and in advocacy. I think it's a good idea to continue that process.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Super stoked that Mastodon is rolling this out after many months of testing.
That even a modicum of effort was put in to address the social failings of quote posting (as implemented on X/Twitter) is already a huge win for online public discourse.
-
trwnh@mastodon.social Yes you're right, some messiness is bound to happen.
I'm not trying to force all implementations into a specific inheritance pattern, that's why it's a "should", not a "must".
Even then one of my concerns is that while in an ideal scenario, everybody inheriting their parent context leads to an entire collection all referencing the same context... in reality a lot of messiness will occur, objects will reference other contexts all over the place, etc.
At the end of the day it's best effort, and if we are able to handle all that and still get to a point where backfill is achievable, then that's a win in my books.
> it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact)
Part of me would like this to not happen, but it is unavoidable.
-
ยปMastodon rolls out quote posts with protections to prevent โdunkingโยซ https://techcrunch.com/2025/09/12/mastodon-rolls-out-quote-posts-with-protections-to-prevent-dunking/?Fedizen.EU #Fedizen #Fediverse #ActivityPub #News
-
@julian @nutomic for example, some impls attach replies even if they do not share the same context, as a compatibility measure. that kind of stuff
-
@julian @nutomic i think it's unavoidable that at some point you will end up having to recognize that two context ids may be equivalent, perhaps with one of them being canonical. "cached representation of remote content" is fine and there isn't necessarily a problem there. it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact)
-
Good question โ in my opinion, 7888 serves as a gentle introduction into the entire concept of conversational contexts. It's meant to be descriptive in order to capture the variety of existing implementations of context that are found in the wild (e.g. Pleroma context which doesn't resolve, contexts that are not URLs, etc.)
Each subsequent FEP "down the tree" (or up, depending on how you look at it) narrows the scope and upgrades verbiage in order to enable additional functionality.
Specifically pertaining to 11dd:
Ownership is explicitly defined and is now a requirement, 7888 mentioned attributedTo and context ownership as examples only. This upgrade was done to set the stage for subsequent FEPs for forking, merging, moving, etc. Activities should be sent to the context owner. This is identical to 7888, but re-stated as a reminder. A specific recommendation for inheritance is included (adopt the immediate parent's context, more if able), while 7888 allows for one to drop context altogether, inherit, or create your own.This is not to say that 7888 is deficient in any manner. On the contrary, it's working entirely as intended!
In practice, Lemmy has adopted 7888, but at this time will not adopt 11dd. nutomic@lemmy.ml creates a context local to the instance, for each post because each instance is expected to be the canonical representation of the context, even if they are cached representations of remote federated content.
It means it would preclude Lemmy from adopting further upgrades like forking/merging/moving/locking, but it doesn't mean they are wrong in doing so.
-
There are many opportunities for ActivityPub and ATProto developers and operators to collaborate: at standards bodies like IETF and W3C, in conferences, and in advocacy. I think it's a good idea to continue that process.
-
Thanks to everyone who replied. I agree with the vast majority on this.
