a.starrysky.fyi
targeting
main
from
a.starrysky.fyi/tranquil-pds:
private/minion/push-qxsvvqowootl
Anisota seems to be using these in a way which attempts to proxy them - unfortunately they aren't actually meant to be proxied and fail... the list records method outright returns XRPCNotSupported and the get record method gives RecordNotFound
...we just, like, shouldn't be proxying it. Avoiding proxying completely fixes this issue...
None yet.
None yet.
Anisota seems to be using these in a way which attempts to proxy them -
unfortunately they aren't actually meant to be proxied and fail... the
list records method outright returns XRPCNotSupported and the get record
method gives RecordNotFound
...we just, like, shouldn't be proxying it. Avoiding proxying completely
fixes this issue...
ack, thanks - didn't realize this would break bluesky - I'll see if I can chat about this with anisota team instead and figure out if there's some reverse proxy hack I can do to stopgap for myself then... I guess there's not much that can be done here (I'm at the airport now, but I'll close this and rebase #21 when I have a few moments)
tranquil.farm
the main issue here is that social-app and its forks make getRecord calls that they do expect to be proxied (or at least the not-quite-proxying-but-has-the-same-effect fallback implementation of the reference pds). so blocking proxying of this would break replies for the vast majority of bluesky users on tranquil.
from a purely design pov too this kind of goes against some of the core values of tranquil. we want to implement spec not whatever weird things buggy clients expect. if anisota truly doesnt want those requests proxied then it shouldnt set the proxy header for them. doing so is a bug.
we reluctantly accept that the vast majority of atproto users use bluesky so we have to implement a fair bit of special-case out of spec things for it to work but the goal is eventually to remove that too once atproto itself and the reference implementation catches up to the needs of bluesky.