• 1 Post
  • 20 Comments
Joined 2 months ago
cake
Cake day: January 21st, 2025

help-circle








  • Guppe Announces the original post, and the replies to it, but doesn’t Announce anything else. For the replies, it also does what PeerTube does and sends out them unsigned, for instances to verify using the LD signature in the activity, or to fetch from the source. If you want to meaningfully vote on something that came from a.gup.pe, you have to send it to the original author, not to a.gup.pe like you would if you were voting from something from Lemmy, because a.gup.pe will just silently drop it.

    Lemmy’s communities Announce everything, but Mastodon only comprehends Announce as a Boost, so it just rejects the Announce of anything that’s not a Page or a Note. There are other platforms though (e.g. Friendica) who will see the Announce of a Like, and go fetch it from it’s source (most non-Lemmy platforms don’t trust Lemmy-style Announces, because whilst it’s against the spec for Announce contents not to be an exact copy of the original activity, there’s nothing stopping a rogue community from misrepresenting users or undoing their intentions).






  • Looks like I was wrong before: whilst it’s true that Lemmy isn’t always great at sending an ‘Accept’ back, that’s not the issue here. I was thinking about it from the perspective of a Person following a Group, not a Group following a Group.

    It’ll be interesting to see how the Lemmy devs respond. It’s not really relevant for PieFed, because I’m not sure that there’s communities there that have enough activity to warrant syncing to a category, but I thought about what would happen if you tried, and it would fail. The follower would be checked to see if they are a Person, and the request would go no further if not (there’s no handy error returned, though).

    I’m not sure it would be possible to enable, with the way the database is currently set up. We have a ‘community_member’ table, that looks like:

    pyfedi=# \d community_member
                             Table "public.community_member"
          Column      |            Type             | Collation | Nullable | Default
    ------------------+-----------------------------+-----------+----------+---------
     user_id          | integer                     |           | not null |
     community_id     | integer                     |           | not null |
     is_moderator     | boolean                     |           |          |
     is_owner         | boolean                     |           |          |
     is_banned        | boolean                     |           |          |
     notify_new_posts | boolean                     |           |          |
     created_at       | timestamp without time zone |           |          |
    Indexes:
        "community_member_pkey" PRIMARY KEY, btree (user_id, community_id)
        "ix_community_member_is_banned" btree (is_banned)
    Foreign-key constraints:
        "community_member_community_id_fkey" FOREIGN KEY (community_id) REFERENCES community(id)
        "community_member_user_id_fkey" FOREIGN KEY (user_id) REFERENCES "user"(id)
    

    So if the ‘user_id’ was actually a Group instead of a Person, then it would have a join to the wrong table.


  • Yeah, as mentioned - Lemmy is often quite bad at sending the ‘Accept’ back for a Follow. It’s particularly the case if the instance hasn’t heard of you before, because in the process of fetching your user and instance details, it ‘forgets’ about the Accept. Within Lemmy, everyone’s sort of got into the habit of ‘Subscribe / Unsubscribe / Subscribe’. (where the first ‘subscribe’ lets them get your details, and the second one actually gets an ‘Accept’ back.)

    PieFed is more reliable at sending ‘Accept’ back, so it’s maybe useful to check your logic from this end with a community from there, e.g. https://piefed.social/c/antisocialmedia



  • @darkpollo I’ll have a go at answering some of your questions, until something better comes along.

    1. Yes. Here’s your reply on another server: link

    2. Yes. I tested out creating and then deleting stuff from a remote account, and this forum acknowledged both.

    3. Remote users don’t get any privileges - their profile on this forum is just a text copy of the one they have on their own platforms. In terms of identifying local vs. remote (visually, at least), you can hover over users and see whether they have an ‘@’ in their name. You could do the same programmatically, but I imagine that there’s better ways.