Conversation

Notices

1. Embed this notice
   marius (mariusor@metalhead.club)'s status on Sunday, 15-Feb-2026 03:19:36 JST marius

   I'm thinking in adding #ONI proxyUrl support in the frontend. :goose_hacker:

   Currently if a request to a remote #ActivityPub object fails - either due to CORS, or because of authorized fetch - I just display a fallback link to it.

   I'm wondering if I can do a two step approach, if the request to the resource fails with 401-403 (for secure fetch) or 400 (for CORS failures) I try to redirect the request through the proxyUrl mechanism.

   Only if that fails too, I fallback to something else.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 15-Feb-2026 03:19:31 JST silverpill

     in reply to

     @mariusor No worries, I was deploying an update :]

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Sunday, 15-Feb-2026 03:19:33 JST marius

     in reply to

     • silverpill

     Ooops... mitra.social is down.

     I hope it wasn't me that brought it down with my testing. :(( Sorry @silverpill

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Sunday, 15-Feb-2026 03:19:35 JST marius

     in reply to

     :🎉 ... and done!

     Now I have the actors of remote instances (like mitra.social and mastodonapp.uk) loading properly in the inbox of ONI.

     I'm not proud of the JavaScript that does it, there must be an idiomatic way to chain fetch requests without the Promise in Promise spaghetti I just wrote. :(

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 15-Feb-2026 03:22:29 JST silverpill

     in reply to

     @mariusor

     Now I have the actors of remote instances (like mitra.social and mastodonapp.uk) loading properly in the inbox of ONI.

     Are mitra.social actors special in some way?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 15-Feb-2026 04:07:21 JST silverpill

     in reply to

     @mariusor Yes, mitra's CORS config is a bit weird. I plan to change it to a more permissive one in the future

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Sunday, 15-Feb-2026 04:07:23 JST marius

     in reply to

     • silverpill

     @silverpill when I fetch mitra actors from the browser with JavaScript fetch, it disallows them due to the server not allowing CORS pre-flight requests.

     When I was adding support for Django's C2S client, it became apparent that if we want objects be accessible form in browser clients, the servers need very relaxed CORS policies. I defaulted to accepting all https:// ... but I'm thinking about rules based on the actor's followers perhaps..

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 15-Feb-2026 08:31:27 JST silverpill

     in reply to

     @mariusor I have allowed all origins on mitra.social

     Other instances will continue to use allowlist for the foreseeable future (until the major version bump).

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Sunday, 15-Feb-2026 08:31:28 JST marius

     in reply to

     • silverpill

     @silverpill can't wait... the good thing about my implementation of using proxyUrl from the frontend is that it only kicks in on failed requests, so it'll be transparent when you switch.