snoopy@jlai.lu personally, since I create AP enabled software I am on the side of votes being public data. We already have enough issues with votes being out of sync with each other. Mixing in private voting is just asking for trouble. Emoji reactions are neat, although niche to those softwares that utilise it. They allow for greater expression which is nice. They're useless for deriving value (for ranking purposes) unless you assign value to them.

I suppose you're right in a way. The context owner is not supposed to be set by someone other than the context owner. It's a fallback mechanism intended for better compatibility with Mastodon. When a group is addressed and it is one of the local NodeBB categories, it will assume control If it is another group that it knows about but isn't same origin to the author, then no category is assumed.

trwnh@mastodon.social before, I was not sending Accept at all, now I am sending application/jrd+json.

Hey rimu@piefed.social thanks for responding (and sorry for the late reply!) I am not married to the Announce([Article|Note|Page]) approach, so I am definitely open to Create([Article|Note|Page]) with a back-reference. I think I went the former direction because there is a known fallback mechanism — the Announce is treated as a share/boost/repost as normal. However, sending the Create also is fine I think. However, do we need a backreference? In my limited research, it seems that Piefed, et al. picks the first Group actor and associates the post with that community. If I sent over a Create(Article) with two Group actors addressed, could Piefed associate the post with the first, and initiate a cross-post with the remaining Group actors? Secondly, is how to handle sync. 1b12 relies on communities having reciprocal followers in order for two-way synchronization to be established. On my end since I know it is cross-posted I will now send 1b12 activities to cross-posted communities, but can Piefed, et al. send 1b12 activities back as well, in the absence of followers? cc andrew_s@piefed.social nutomic@lemmy.ml melroy@kbin.melroy.org bentigorlich@gehirneimer.de

@mastodonmigration@mastodon.online while this is a known workaround, I don't think it's a tenable long-term solution. You can have "real decentralization" without the quirks, too.

@philipp@social.anoxinon.de I kind of think this is really missing the forest for the trees if your rational is CO2 emissions... I mean, a far greater generator of CO2 emissions would be every single Mastodon instance caching every piece of media it sees...

@julian yes we've had this for 6+ months