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.

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.

I would get downvoted to oblivion if people can downvote me, but I think people are really overreacting w/ the Meta stuff. I already ranted about it a bit on my blog article, but the gist of it is:

Nothing has even happened yet. There’s no “Meta instance” federating right now, and even if there is, you and your community has the power to just… block them off when it happens! The code is open, the community is yours, and you can do whatever you want, but your actions so far have involved attacking and harassing this person off the Fediverse, something that they contributed so much towards!

All the reaction that I’ve seen are just preemptive “get off my turf” reaction. It makes me annoyed that people are just going along with this mob.

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?)