Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @mike@macgirvin.com
silverpill@silverpill@mitra.social (2026-06-10 19:27:43)
@mike
I might argue that what this represents is quite literally a "filtered view"...
That's fine, I fixed it on my side.
However, now I'm getting 403 responses when ?posts=true is present. At the same time, unfiltered collection can be retrieved without issues.
My normalised-comparison function doesn't alter the original. Will review the portable objects implementation shortly and make certain I got that part right.
The normalization algorithm recommended in FEP-ef61 removes query parameters because there is a magic query parameter gateways, which is used for location hints:
ap://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor?gateways=https%3A%2F%2Fserver1.example,https%3A%2F%2Fserver2.example
I thought that there will be more magic parameters and decided to "reserve" the entire query component (quoting section 'ap' URIs):
The query is OPTIONAL. To avoid future conflicts, implementers SHOULD NOT use parameter names that are not defined in this proposal.
But of course, we need them to filter collections, so this is not a hard requirement (SHOULD, not MUST)...
But I would be happy to implement it if it would allow us to all co-exist in the same fediverse.
I think a filtered view is fine, but you could also choose to not publish this collection - it is not required by FEP-f228. Other implementations should be able to backfill conversation using the contextHistory property.
---Reply---
Mike Macgirvin@mike@macgirvin.com (2026-06-11 07:01:55)
Conversation owner can add any activity to the conversation. However, if a context property is present on the activity, its value SHOULD be identical to the ID of a conversation container.
Let's just remove this line from FEP-171b. Then I think I can make most everything else work.
Tying the conversation target to the context in any way, shape, or form appears to be un-workable. That includes tying it to contextHistory instead. Thy are separate concepts, although implementations MAY choose to use the same identifiers for both.
About the 403 - was it fetched by your site actor perchance? They aren't one of my followers. I'm not seeing any permission issues currently, though I'll keep investigating.
Reply
---Replies---
silverpill@silverpill@mitra.social (2026-06-11 19:06:01)
@mike
About the 403 - was it fetched by your site actor perchance? They aren't one of my followers. I'm not seeing any permission issues currently, though I'll keep investigating.
No, I am making a request on behalf of my personal actor. Made another attempt at 2026-06-11T10:03:56Z with the same result.
Let's just remove this line from FEP-171b. Then I think I can make most everything else work.
OK, I will remove it.