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

October 2025 ForumWG Meeting


Gli ultimi otto messaggi ricevuti dalla Federazione
  • @trwnh@mastodon.social sure here are the minutes!

    I was the only member in attendance 😁 The meeting was adjourned with zero action items
    read more

  • @julian sorry for oversleeping today -- any minutes?

    read more

  • Monthly meetings are held on the first Thursday of each month, at 13h00 to 14h00 Eastern Time (currently 18h00 to 19h00 UTC). You can find them listed in the SocialCG Calendar. The next meeting will be held (today) on 5 February 2026.

    Meeting link: https://meet.jit.si/ap-forum-wg

    There is no set agenda for this month's meeting.

    @julian will discuss a new FEP-f15d: Context Relocation and Removal and integration efforts with the Lemmy and Piefed folk. Updates re: FEP-4f05: Soft Deletion and WordPress and Mastodon's efforts to implement
    read more

  • @silverpill@mitra.social said in Minutes from 4 December 2025 WG Meeting:
    > It's not possible to sign a dynamic object, because some of its properties are constantly changing (items, totalItems and others). This means collections need to be always server-managed. Therefore, clients shouldn't be allowed to directly create, update or delete them.

    Mmm, signing doesn't guarantee data correctness, it only guarantees that the data presented is correct as of sending, per the sender's point of view.

    Just like how signing a Create(Note) only guarantees that the note's data is what it is at the time of the Create, a Move(Context) only guarantees the validity of the context's data at the time of the Move.

    That said, this FEP doesn't have you including the entire object in, just the URI, so this is moot........ no?

    read more

  • Sorry it took so long to respond to this —

    Re: assumption of a context belonging to one audience
    > Where, in Lemmy? Even if some implementations don't support cross-posting I don't see a reason to block it at the protocol level.

    This FEP doesn't block cross-posting at the protocol level. Move just explicitly states that a context was Removed from one and Added to another. You could achieve this just fine with Remove followed by Add, but this just reduces it down to a single activity and eliminates any side-effects (e.g. a Remove without corresponding Add might mean content is purged from the db)

    So in theory, a context can belong to multiple audiences, and it can be moved from one to another, or removed from one.

    read more

  • Collections are dynamic objects because they can be paginated and filtered. It's not possible to sign a dynamic object, because some of its properties are constantly changing (items, totalItems and others). This means collections need to be always server-managed. Therefore, clients shouldn't be allowed to directly create, update or delete them.

    I think the proposed Move activity is an obfuscated Update because it changes the collection directly.

    read more

  • >the assumption is already there

    Where, in Lemmy? Even if some implementations don't support cross-posting I don't see a reason to block it at the protocol level.

    And Update is simpler, that's one activity instead of two (Move and Remove).

    read more

  • silverpill@mitra.social said in Minutes from 4 December 2025 WG Meeting:
    > 2. Treating collections (dynamic views) as static objects that can be moved, deleted etc is not compatible with client-side signing.

    You mentioned this before, but I am not sure what you are referring to. Do you mind elaborating?

    read more
Post suggeriti
  • 0 Votes
    2 Posts
    8 Views
    I have to properly do it in wafrn, but its a good idea tbh. Its GTS interaction policies, more software should implement it! Me included
  • Yay!

    Moved Random mastodon plushtodon activitypub fediverse
    1
    3
    0 Votes
    1 Posts
    8 Views
    Yay! My #Mastodon trifecta is now complete! My blue & orange (is it orange‽) #Plushtodon came in last night, & I opened it yesterday, but I was too tired to post about it as I just got off work. But yes, I am excited that the two smaller Plushes arrived! Thanks @Mastodon for creating these!Also…we need more #ActivityPub apps to create real world wearables or plushies, as they are great conversation starters for folks who are not familiar with the #Fediverse.
  • #FediNews

    Moved Uncategorized fedinews fediverso activitypub
    1
    1
    0 Votes
    1 Posts
    8 Views
    #FediNews Lanzamiento de una herramienta para mejorar la interoperabilidad: El Applied Social Media Lab lanzó recientemente "The ActivityPub Fuzzer", un programa diseñado para emular datos en todo el #fediverso para ayudar a mejorar la interoperabilidad entre diferentes plataformasEl ActivityPub Fuzzer | Laboratorio de Redes Sociales Aplicadas - YouTubehttps://www.youtube.com/watch?v=EGo7ZaBG-4s #ActivityPub
  • 0 Votes
    15 Posts
    51 Views
    trwnh@mastodon.social Yes, you're right. There are nuances and situations where you would explicitly not want to inherit the root object's context. I am dealing with the typical day-to-day use case of replying to an object with the expectation that is be part of the same existing context. However I am more than happy to make this clear in the FEP and spell out alternative situations where context inheritance would not apply. The situation I found myself in was one where anybody can (and does) include whatever context they want. In that case, it's difficult to determine whether disparate contexts are actually referring to a common set of the same objects, or whether they were disparate on purpose (i.e. a fork.) To that end, it meant that as a receiver there was no guarantee that any contexts I'd be sent would map to any contexts I know. Strict root-level inheritance for the common use-case would at least disambiguate a lot of this.