Salta al contenuto

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

Topic removal from a category/community

Technical Discussion
14 5 3
  • There are lots of other uses for Move. A community whole could move instances, a user could move instances, etc.

    Yeah you're right, Move has some prior art for account migrations so it's worth some thinking through.

    I'd like to work together on this though. I'm working through context ownership and inheritance first, but once that FEP is drafted I can move on to this.

  • Yes, a Delete activity is sent to all instances with actors that follow the category/community. Those instances then delete their local copy. In Lemmy/PieFed there is no distinction between deletion and removal.

    The deletes are soft so it is possible to un-delete by sending an Undo activity. PieFed keeps soft-deleted posts (topics, in NodeBB language) for a few days then after a week deletes the content from the database.

    All of these activities are enclosed in an Announce and the http POST is signed using the community key. So in a way the content 'belongs' to the community, not to the original author. With that model of ownership the idea of removal redundant - a post without a community is not a post.

    Tangentially - it would be good to come up with a way to move a topic to another category and federate that so the move can happen on other instances, too. We could go off-piste and create a Move activity, or use Remove (from old topic/comm) followed by Add (to new topic/comm) to do the same thing. I feel more inclined to go with Move as it's a single atomic operation that either succeeds or fails, despite it not being in the spec.

    The AP spec is so badly stretched by various implementation-specific differences that I don't think it's worth being ideological about adherence to it it anymore.

    rimu@piefed.social said in Topic removal from a category/community:
    > All of these activities are enclosed in an Announce and the http POST is signed using the community key. So in a way the content 'belongs' to the community, not to the original author.

    Oh that's right! That makes sense. Having the community sign the activity (and the Announce wrapper) would effectively differentiate it from a simple author-initiated content deletion.

    The impetus for this question was that occasionally I will move topics out of a category for being off topic. Federated copies don't see this change reflected, so both Move and Delete are things I want to federate out in lockstep with Piefed and Lemmy.

  • Yes, a Delete activity is sent to all instances with actors that follow the category/community. Those instances then delete their local copy. In Lemmy/PieFed there is no distinction between deletion and removal.

    The deletes are soft so it is possible to un-delete by sending an Undo activity. PieFed keeps soft-deleted posts (topics, in NodeBB language) for a few days then after a week deletes the content from the database.

    All of these activities are enclosed in an Announce and the http POST is signed using the community key. So in a way the content 'belongs' to the community, not to the original author. With that model of ownership the idea of removal redundant - a post without a community is not a post.

    Tangentially - it would be good to come up with a way to move a topic to another category and federate that so the move can happen on other instances, too. We could go off-piste and create a Move activity, or use Remove (from old topic/comm) followed by Add (to new topic/comm) to do the same thing. I feel more inclined to go with Move as it's a single atomic operation that either succeeds or fails, despite it not being in the spec.

    The AP spec is so badly stretched by various implementation-specific differences that I don't think it's worth being ideological about adherence to it it anymore.

    @rimu Still, I think it would be nice to deprecate Delete and slowly migrate to Remove(target: context), since both PieFed and Lemmy implement the context collection now.

    My server rejects Delete if its actor is different from object's owner, and I have to treat Announce(Delete) as a special case where the normal processing logic doesn't apply.

  • @rimu Still, I think it would be nice to deprecate Delete and slowly migrate to Remove(target: context), since both PieFed and Lemmy implement the context collection now.

    My server rejects Delete if its actor is different from object's owner, and I have to treat Announce(Delete) as a special case where the normal processing logic doesn't apply.

    Possibly although the differences of federation between the threadiverse and the rest of the fediverse go way beyond deletes. FEP 1b12 is a whole thing, chipping away at it piece by piece would be slow going.

  • Possibly although the differences of federation between the threadiverse and the rest of the fediverse go way beyond deletes. FEP 1b12 is a whole thing, chipping away at it piece by piece would be slow going.

    Personally I think 1b12 doesn't need to be changed or hacked around. It doesn't specifically call for federating out deletes so I'd think any solution we come up with together would work with that FEP, not go against it.

    cc silverpill@mitra.social (if your app notifies you of new replies without a direct mention I'll stop tagging you too)

  • Personally I think 1b12 doesn't need to be changed or hacked around. It doesn't specifically call for federating out deletes so I'd think any solution we come up with together would work with that FEP, not go against it.

    cc silverpill@mitra.social (if your app notifies you of new replies without a direct mention I'll stop tagging you too)

    I also think that backfill will have a side effect of connecting the threadiverse and the rest of the fediverse.

    Exposing context collections will mean consumers will be able to see both *verses. Once Mastodon starts consuming them I predict you will start seeing much more engagement from the microblogs.

    The same would apply if Piefed or Lemmy begin consuming them as well.

    That is an angle I had not even considered until now!

  • Personally I think 1b12 doesn't need to be changed or hacked around. It doesn't specifically call for federating out deletes so I'd think any solution we come up with together would work with that FEP, not go against it.

    cc silverpill@mitra.social (if your app notifies you of new replies without a direct mention I'll stop tagging you too)

    @julian

    if your app notifies you of new replies without a direct mention I'll stop tagging you too

    Inclusion in to or cc is enough to generate a notification.

  • Possibly although the differences of federation between the threadiverse and the rest of the fediverse go way beyond deletes. FEP 1b12 is a whole thing, chipping away at it piece by piece would be slow going.

    rimu@piefed.social silverpill@mitra.social I gave this a bit more thought and I am coming around to the idea that Remove could work.

    I am assuming that when Piefed sends Announce(Delete(Object)) this is only understood by Piefed? Not Lemmy (and certainly not NodeBB, yet)...

    In that case, a move to a simpler Remove(target: context) signed and acted on by the community actor, would send a more explicit message that the object was removed from the community.

    The "1b12-speaking" portion of it would be an Undo(Announce(Create)), although once again I am not even sure if that action is understood by Piefed/Lemmy.

  • only understood by Piefed? Not Lemmy

    No, that's a Lemmy thing too.

  • only understood by Piefed? Not Lemmy

    No, that's a Lemmy thing too.

    Oh okay. I wasn't sure about that since I don't think it's documented in the FEP, though it's been awhile since I've given it a read through.


Gli ultimi otto messaggi ricevuti dalla Federazione
  • Mastodon has a concept called "pinned statuses", which is a special collection attached to a Person actor.

    https://docs.joinmastodon.org/spec/activitypub/#featured

    It wasn't readily known how this collection is updated and federated (not without code achaeology), but claire@social.sitedethib.com recently shared some additional info :smiley:

    The actor itself will issue an Add activity targeting the collection with the status in object. This activity is sent to all followers of the actor. No activity is sent if the actor has no remote followers. A Remove is sent when a pinned post is unpinned.

    This is what the Add looks like:

    { "@context": "https://www.w3.org/ns/activitystreams", "type": "Add", "actor": "https://example.org/users/testUser", "target": "https://example.org/users/testUser/collections/featured", "object": "https://example.org/users/testUser/statuses/115266412340579560" }

    The corresponding Remove is identical except for type, which is of course, Remove.

    per saperne di più

  • Oh okay. I wasn't sure about that since I don't think it's documented in the FEP, though it's been awhile since I've given it a read through.

    per saperne di più

  • only understood by Piefed? Not Lemmy

    No, that's a Lemmy thing too.

    per saperne di più

  • rimu@piefed.social silverpill@mitra.social I gave this a bit more thought and I am coming around to the idea that Remove could work.

    I am assuming that when Piefed sends Announce(Delete(Object)) this is only understood by Piefed? Not Lemmy (and certainly not NodeBB, yet)...

    In that case, a move to a simpler Remove(target: context) signed and acted on by the community actor, would send a more explicit message that the object was removed from the community.

    The "1b12-speaking" portion of it would be an Undo(Announce(Create)), although once again I am not even sure if that action is understood by Piefed/Lemmy.

    per saperne di più

  • @meduz I know, I’m looking for somebody who says “I have done all those experiments and this is the best setup”

    per saperne di più

  • @j12t The most adopted standard for this is Open Graph (created by Facebook): https://ogp.me ; Mastodon and many others follow it, but I don’t know for Bluesky.

    For image sizes, there is no standards, thou you can try or pick a lot of websites as example by checking their `og` HTML meta. If the pic size is too small, Mastodon might take the favicon instead and slightly change the presentation.

    per saperne di più

  • The change to how post flair federate was done with the 1.2 release. We tried to mirror the json structure as it currently stands with the planned lemmy 1.0 release (schema here).

    We have some extra fields for indicating the text color and the background color of the post flair as well as whether the flair should apply a blur effect to the post preview (for things like spoiler posts). Lemmy hasn't yet finalized how they will schematize the color properties yet. You can see and contribute to the ongoing discussion here.

    We will be updating our schema as theirs comes more into focus to try to keep the interop and transition as smooth as possible. If you want to see an example of an existing community that makes heavy use of post flair, you can look at !fediverse@piefed.social.

    per saperne di più

  • @jon I'm using that, and Bluesky pulls out an image, but the aspect ratio of that image appears to be all wrong, so Bsky crops it in weird ways. What I'm looking for is 1) a bluesky-specific OpenGraph tag -- like there is one for Twitter and 2) just what the heck is the aspect ratio supposed to be on Bsky?

    per saperne di più
Post suggeriti