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!
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).
No plans for a Docker image atm but you should be able to easily host this using any web server! It just needs to be built, and I might make a Github Action to automate that.
For now, the site is fully static and doesn’t require any server so you can just use the one hosted on Netlify.
I don’t really have a choice here, see https://github.com/LemmyNet/lemmy/issues/3109
Yup! Each profile will eventually be its own (possibly anonymous) account that belongs to an instance, something like this:
Whoops! I forgot to update it.
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.
Here’s what I have planned at the moment: https://hachyderm.io/@diamond/110564684274449852
I don’t plan on making it feature-complete, just enough to be a Lemmy reader with some reply capabilities.
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.
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.
My name (Diamond) mostly came from my username. I used to be more active talking on Discord, so a lot of my friends would call me based on my username. It was weird at first, but I got used to it! Some people found it surprising, but the reactions aren’t too bad.