Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @silverpill@mitra.social
Mike Macgirvin@mike@macgirvin.com (2026-06-10 09:04:43)
I might argue that what this represents is quite literally a "filtered view"...
But I could use a path instead.
My normalised-comparison function doesn't alter the original. Will review the portable objects implementation shortly and make certain I got that part right.
---Reply---
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
---Replies---
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.