I don't know anything about it but on the surface it seems fitting here... hopefully you don't mind me creating a tracking ticket here 😅

Have a nice day! 👋

Private groups?

I'll definitely switch to that

After GitHub and Codeberg, https://keyoxide.org/[email protected] points now to my self-hosted website 🙂

I'm always frustrated when I need to send a JSON request to GoToSocial user. In other implementations, there's just a single /inbox (sharedInbox endpoint) and the server figures out how or where to route the activity. Not so in GoToSocial.

The docs acknowledge this:

GoToSocial accounts do not currently implement a sharedInbox endpoint, though this is subject to change.

Describe the solution you'd like.

I'd like GoToSocial to expose sharedInbox endpoint for all users.

Describe alternatives you've considered.

I've considered not interacting with GoToSocial users as this is additional friction but I want to avoid that if possible.

Additional context.

None, I haven't seen a backing ticket for this, that's why I'm creating it.

Have a nice day! :wav

So, I think the easiest workaround here would be reading the Location header without following requests and retrying with the target URL. Yep, it's not as clean as it should be but IMO the complexity stems from the JMAP spec that clearly didn't analyze impact of GET requests with authorization across domains (which I consider a quite significant use-case).

I wonder if the missing credentials thing is something that only happens on redirects across domains. Because I’m reasonable sure that in the testing I did with Cyrus there was also a redirect from .well-known/jmap to /jmap (or something)

Ugh, you've nerd-sniped me into looking at that and the good news is you're spot on (header lost on changing domains) but the bad news is that it seems to be by design:

Quoting the spec:

If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm

Also here:

The realm value (case-sensitive), in combination with the canonical root URL of the server being accessed, defines the protection space.

I haven't seen realms being used in Bearer tokens but they are specified.

Additionally I found a Browser compat section which tracks the "Authorization header removed from cross-origin redirects" feature: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization#browser_compatibility

Interestingly, there's a question on stackoverflow discussing the same problem (suggesting several workarounds).

The final nail to the coffin seems to be the okhttp ticket where users asked for this feature to be configurable and closed as "won't fix".

It looks like the login ("[email protected]" here) is only sent with the first request, but not in the second one to the redirect target.

I reached the same conclusion when trying to setup Fastmail integration with:

location ~ /.well-known/jmap {
    return 301 https://api.fastmail.com/.well-known/jmap;
}

I guess setting up a proxy which forwards all headers would work but I wonder if the HTTP client of Ltt.rs can be configured to resend auth headers on redirects...

Ltt.rs currently doesn’t do automatic discovery via DNS because this essentially requires DNSSEC.

I've got DNSSEC enabled and it didn't work so I assume this is not implemented. I wonder if minidns could be used for that.

There's also another alternative: do the https://<userdomain>/.well-known/jmap request with no redirects enabled, read the Location header and proceed with the header value as if it has been entered by the user. That'd mean the Authorization headers would be sent to correct target servers and everything would work seamlessly.

One way or another, using Ltt.rs is such a breeze of fresh air compared to old e-mail clients. Thanks for your efforts, they really show! 👋