Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @mike@macgirvin.com
Mike Macgirvin@mike@macgirvin.com (2026-06-10 09:18:09)
But I could use a path instead.
Actually it appears that no, I cannot. Then it is a different object in the eyes of conversation containers. (Because it is a filtered view). I don't see a lot of ways out of this dilemma that doesn't involve breaking something..
[Edit: maybe being silly, but I could send back an array of collections, with the preferred presentation first. What we called multipart/alternative back in the old days. Most software will probably not handle this well, and I'm not even certain my own would. But I would be happy to implement it if it would allow us to all co-exist in the same fediverse.]
---Reply---
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
---Replies---
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.