I made my own app at Slemmy!

Thanks to the CORS PR that I made to upstream Lemmy, all web clients should now be a lot easier to maintain, so I’m resuming work on mine as well!

Yeah, it’s at https://slemmy.libdb.so, the source code is also on my github!

Heads up, it doesn’t currently work with Lemmy v0. 18.0. PR https://github.com/LemmyNet/lemmy/pull/3301 tracks this. If you or anyone can contribute to this, please do!

I use the one that I made! It was made rather early on before most of these apps became popular, but if it’s my own app, I can make it however I want…

+1 on SchildiChat here as well.

I used to use FluffyChat but it would corrupt its internal SQLite database randomly. That happened a couple of times so I just stopped using it entirely.

I’m adding this into my Lemmy client’s README.

Shameless plug (sorry) but I’m working on one too! It’s a web app that works on both desktop and mobile: https://slemmy.libdb.so.

It is a free-time kind of project (I work on it after my actual working hours), so it might not grow at the same pace as other newer apps, but I’m trying!

Source code is at https://libdb.so/slemmy, AGPLv3 license.

P/S: the app currently lives at https://slemmy.libdb.so.

Thank you for the reply, I really appreciate it! Currently, my app has been migrated to the WS API so development can continue for now until the WS is removed completely in a later release or Lemmy addresses the CORS issue upstream.

As for the security concerns, I believe that most of them are addressed in this comment that is in the particular issue that I linked above.

It’s worth noting that CORS really only applies in the browser and that the WS API currently bypasses this protection (hence me being able to continue with the development).

I don’t really have a choice here, see https://github.com/LemmyNet/lemmy/issues/3109

The websocket needs the right URL or it won’t work, you can’t always assume the websocket endpoint is at the root of the domain.

Right. I was reading a code snippet from somewhere else where they called into the root path, but the library that they were using probably did the appending in the background which I didn’t know.

That’s annoying, though, because setting up the right CORS headers to allow arbitrary online clients is a pain and I suspect many instance admins won’t do it.

There is an issue upstream tracking this. For now, I only mostly use Beehaw, so that’s fine.

As a side note, are you implementing the API from scratch? Because there’s a Javascript (Typescript) API that gets auto generated from the Lemmy sources that’s ready to use (supports both REST and WS).

Nope, I’m using lemmy-js-client. The WS part of it doesn’t do much, so I didn’t bother using it. The LemmyWebsocket type wasn’t also in the main import for some reason, but that wasn’t much of an issue.

Huh, interesting. It seems that a WS connection to wss://beehaw.org/api/v3/ws works, but not wss://beehaw.org. I remember reading somewhere that the WS API will eventually be removed, though.

I’ll continue development w/ the REST API until I feel like it’s in a mostly-working state, and then I’ll probably subject myself to the WS API after. Working with the REST API does feel a lot easier.

Websocket handshakes are done over HTTP. The endpoint for Beehaw’s WS API would be wss://beehaw.org/, so it’s still going to use the same CORS policies as accessing the / (root) path.

I had no idea that NGINX has Lua plugins. You’d probably want to check if Caddy has equivalents for those plugins though, or just implement them in Go yourself.

People comment a lot on performance, but I think Caddy can (and should) hold up perfectly fine. It might be worth it to experiment with running servers half on Caddy and half on NGINX, then see how the traffic is being handled by both to compare.

I do think the much cleaner config makes up for the maybe slight performance loss, though. It’s just so much less work to set up and maintain compared to NGINX. The last time I’ve used NGINX was years ago, when I decided to drop it entirely in favor of Caddy. I do think NGINX is only “standard” because it came before Caddy, and that most applications should not prefer it over Caddy.

I think they definitely could’ve made a profile page while keeping the discriminator around. Something like discord.com/u/diamondburned/4507.

(For various reasons diamondburned#4507 is not too ideal for a URL, but it’s a small difference. Right?)