asdfzdfj

prior discussion on kbin side: https://codeberg.org/Kbin/kbin-core/issues/658 --- on attaching the badges to AP representation: another possible way to do this is perhaps making use of [PropertyValue](https://schema.org/PropertyValue), perhaps something like this...

thanks for linking that, that looks interesting. it does raise some good points (for me): - using a custom object (`mbin:Badge` for us, if we somehow ended up with this...

> I think the lock should be aquired when dispatching the message and then passing the lock along with the actor to the message (see [Lock#Serialization](https://symfony.com/doc/current/components/lock.html#serializing-locks)). With your solution you...

perhaps it's just like what benti pointed out, that the goal of this patch here is to prevent multiple update actor handler running on same actor at once (and I've...

ok, I've extended it try and avoid dispatching multiple UpdateActorMessage in the first place with the help of lock keys, *provided that key serialization is available*, if it doesn't then...

ok, I just now came up with even more crazier proposition: if the main thing you want is limit dispatching multiple update actor messages for the same actor, then just...

> Code wise it looks good to me. Did you test it thoroughly? If yes then I trust you that I do not need to test it myself. I have...

> > we lock the actual updating part for 60 minutes per actor, so every actor is at most updated once every hour > > I think this is not...

my quick 2c: - for remote objects: use and save the incoming tags (and mentions), though this _does_ assume that the remote software generate this information correctly - the tags/mentions...

> [kbin.run](https://kbin.run/) almost always runs the latest main (and sometimes experimental PRs...), but I'm guessing this issue is related to #650. thoughts, @asdfzdfj? if you need more info let me...