Skip to content

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
29 5 112

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @silverpill @technical-discussion it's part of the outbox delivery algorithm, which bridges between c2s and s2s. the intention is that the outbox publishes activities via c2s, but then optionally delivers based on addressing properties via s2s

    (this ends up having other issues in practice due to the lack of an envelope, but at least the intent of "relevant activities should trigger notifications for relevant entities" makes sense, per 6.1 clients "look at" some relevant props)

    read more

  • @silverpill @julian @technical-discussion

    example: alice and bob on site.example each have followers collections, but alice can't see bob's followers. if alice addresses bob's followers collection, then alice's outbox can't deliver to bob's followers. alice must address bob, and bob can choose to forward to bob's followers (inbox forwarding)

    if site.example has a collection of "local users" that alice can see, then alice can address it and alice's outbox can deliver to items

    read more

  • @silverpill @julian @technical-discussion

    a "local collection" might still have access control on it.

    (the interface being assumed throughout the AP spec is HTTP, or at least HTTP semantics; "with the user's credentials" in this case means using an Authorization header that lets the outbox access the collection. it's only confusing if you have a monolith with no boundaries between the outbox and anything else; in that case it'd be "lookup the collection in your db/store/etc")

    read more

  • @julian Yes, I think in practice expansion should be performed only for local collections.

    the server MUST dereference the collection (with the user's credentials) is confusing, because it sounds like we're talking about remote collections here.

    @trwnh

    read more

  • @julian well, sure, with a monolithic implementation, the client and the outbox and the delivery agent are all the same app. but they don't have to be. the model is that the client submits to the outbox, and the outbox could also talk to a separate delivery agent internally. it's all opaque from outside the outbox. your internal "outbox" is the code that serializes activities and sends them to the delivery workers.

    read more

  • @trwnh@mastodon.social said in Expanding collections on delivery:
    > say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?

    Simple. My outboxes send a "not supported" HTTP tag 🤣

    But I'm being facetious.

    From a C2S standpoint I suppose that makes sense. Thanks.

    read more

  • @julian now remove the requirement. what do you do instead?

    - if it has ldp:inbox, send an LDN

    ...and that's it. at no point were you ever told or required to do anything else, so your followers/audience/members/etc will never get the activity even if addressed, because the collection was never expanded.

    read more

  • @julian i don't think it's "inferred", and leaving ambiguous cases up to inference in specification is typically called "unspecified behavior" ;)

    say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?

    - in all cases, if it has an `inbox`, you send an LDN to that id if you can.
    - in case it's an as:Collection, you iterate over its items in theory and repeat step 1 recursively. (this is also problematic because it can be both paged+unpaged)

    read more
Post suggeriti
  • 0 Votes
    1 Posts
    8 Views
    One of the long-standing issues we have in/on the fediverse is that when I have a link in my post that goes to another post on my instance, people on other instances will click that link and be taken to MY instance, where they can't comment, don't have an account, aren't logged in, etc and they will try to log in using their login credentials for their home instance then wonder why it doesn't work. When someone links to https://lemmy.world/post/39832275 and I'm on piefed.social I want to see https://piefed.social/c/news/p/1544770/national-parks-ordered-to-check-gift-shops-for-dei-type-items not the copy on lemmy.world! As of PieFed v1.4, links like that will automatically be converted to link to the local copy of the post, where 'local' is whatever is local for the reader. See the linked video where I demonstrate this in action.
  • 0 Votes
    27 Posts
    38 Views
    rimu@piefed.social when the question is federated outward, is it of type of question? 😛 kariboka@mastodon.social
  • 0 Votes
    5 Posts
    32 Views
    Thanks Rimu. I'd link this one directly (and I do, under "Related Communities") but I was hoping for one dedicated to announcements only. No matter, it will work fine :)
  • 0 Votes
    1 Posts
    21 Views
    At Piefed office hours, rimu@piefed.social and I got to talking about what's next for Piefed and the Threadiverse WG. One of those things is moving stuff between communities (or in bbs parlance: moving topics between categories/forums). Rimu suggested we use the already-existing as:Move activity, sent by the community (a group actor), with origin and target set, and with object being the post id itself. I suggested we update this to use the resolvable context collection as object instead, which Piefed has supported since v1.2. That should be enough to get a proof-of-concept implementation going between Piefed and NodeBB... a question remained as to whether this should be Announce(Move(Object)) or simply Move(Object). Argument for former was that it was similar verbiage to other 1b12 actions. Argument for the latter was that this is merely 1b12 adjacent and needn't follow prior art. We'll likely put together an FEP for this.