You shouldn’t be charged for unauthorized requests to your buckets. Currently if you know any person’s bucket name, which is easily discoverable if you know what you’re doing, that means you can maliciously rack up their bill just to hurt them financially by spamming it with anonymous requests.
I know it’s been around for a long time, but I just heard about Real Debrid. My current setup is Wasabi + Rclone + Jellyfin, plus all the *arr services. What’s the benefit of Real Debrid over this setup, aside from cached torrents?
What a sorry state Canada is in when people are hired out of desperation without proper vetting to ensure they are suited to their jobs, even if there is a nurse shortage.
EDIT: Ah thought I was in a Canada community, my mistake. But I guess there are worldwide problems in healthcare these days.
How do people like this even make it far enough to get this type of job?
Same here, I’ve never had this problem, ever. I don’t even get how it’s possible to not know where your files are being saved if you are the least bit techsavvy.
The ending of Soma.
How does this work? At what URL will this be hosted at?
Ah sorry, just remembered I put my entire instance behind authentication except for the API endpoints required for federation. The comment I was linking to is in this thread. Just describes how all the info you need to properly transform the links is right there in the database records of the entities you want to transform, so this functionality can easily be added without much work.
It is actually trivial. Here’s a walkthrough with one solution for how to do it: https://lm.williampuckering.com/comment/723311
It’s actually easy, here’s an explanation for one simple way you could do it.
On my instance, this post has the URL: https://lm.williampuckering.com/post/171615
On the instance the post originated on, the URL is: https://lemmings.world/post/175809
So on my instance, the post has the ID: 171615
On the originating instance, the ID is: 175809
In the database on my instance, this query will retrieve the post:
select * from post where id = 171615
Also in the database on my instance, this query will retrieve the post:
select * from post where ap_id = 'https://lemmings.world/post/175809'
Using the second query and finding the post by URL, I can see if the post is federated to my own instance or not. If so, I can look at the id field in the database and merely swap it out with the originating instance’s ID, and form the URL to access the post as it exists on my own instance. If the post isn’t federated on my own instance, then of course this won’t work. But that makes total sense, since you won’t be able to transform links for external instances to the corresponding entity on your own instance, because it doesn’t exist there.
tl;dr - You can look up local entities by ID, and you can lookup remote entities by original URL. Then you just need to swap the ID in the URL to the ID (primary key in the table) in the database, if it exists, to convert a remote link to a local link. If a link can’t be converted, you can just leave it as-is.
The capability needed to add this functionality is already there. Someone just needs to decide how to handle it on the frontend elegantly from a UI perspective, and decide how the backend will pass what’s required to the frontend to drive the functionality. But the plumbing is already there.
One practical way to go about this would be to add one or more API endpoints to transform remote entities (URLs) to local entities, if they exist. Whenever posts/comments/whatever are loaded into the client’s browser, Lemmy UI can have code that takes any links that match patterns for Lemmy entities, and use the API endpoints to transform the remote URLs to local URLs, if it can be done. For those that can be done, swap the remote URLs on the frontend for the local ones (at this point it’s essentially just find/replace). That’s one quick and simple way to do it that shouldn’t be all that performance-impacting. There might be more elegant and efficient ways I can think of if I put more effort into thinking about this, but that for sure would work and be a decent first-cut solution. You could even add a caching mechanism (or maybe even a new database table) to persist the mapping as it happens so that you don’t need to do it on each request for a given entity, only the first time. Also, doing it this way allows for content that is not yet federated to work if one day it becomes federated (ie. try to do this mapping or each entity, everytime, if it never works, until one day it does).
With all due respect, it seems like a janky solution to have a bot post public comments on request with transformed links specific to a given user’s own instance (that no other users would be likely to care about), just so that they can refresh the page and click on them… If something like this went into widespread use, threads would just become cluttered with comments containing transformed links, and I could see that being really annoying to other users who are trying to properly participate in discussion.
Back on Reddit, I always thought the !remindme bot was pretty dumb. Certain threads would just be spammed with comments for the bot to pick up to remind that specific user on some date to come back and check the thread. We can do better than that here. It was a janky solution to something that was a problem best left to the end-user to manage separately (just set a reminder in your own calendar…).
This is best left to client-side code in the form of a browser addon, or ideally, the Lemmy frontend itself.
It should be trivial to make an enhancement to the official Lemmy frontend such that links to any other Lemmy communities/posts/comments/etc are transformed to the context of the user’s home instance. It could be a togglable setting in the user’s own settings, or maybe both the original link and the transformed link could be presented to the user on click (to accommodate both desktop and mobile browsing).
I’m actually really surprised this isn’t already implemented given how simple it is to do.
I guess they don’t really know what they’re doing and are learning how load balancing works on the fly, and thinking that’ll result in HA without side-effects without further work.
EDIT: Don’t really get why this was downvoted. With the proper technical knowledge it’s clear to anybody that two instances with different JWT secrets behind a load balancer is going to cause this very issue. So the fact that they set it up that way means they have a knowledge gap (“they don’t really know what they’re doing”). At the very least they should enable sticky sessions on the load balancer if they insist on going this route, which would mitigate the issue (but depending on client-side configuration would not necessarily prevent it completely).
Don’t take this as an insult towards the admins of the instance, I’m just pointing out there’s a lack of knowledge, and some trial-and-error going on.
The Linux distro concept is a great analogy.
Oh yeah for sure. It’s just a matter of time. Out of all of these options, some will just fade away (some already have within weeks of initial release), and some will remain and just continue to get better as the development community continues to get a better picture of where all of the action is, and starts to want to be a part of it.
You’re seeing that toast about versions since backend version 0.18.0 switched away from using a websockets-based API to a REST API, and the Jerboa client app is (in a not-so-descriptive way) warning you that the backend you are connected to isn’t aligned with the app version in terms of what it expects of the backed. This should go away pretty soon as more servers update their backend version and the Jerboa app update hits more devices.
It’s awesome to see Lemmy getting lots of love, and choice in the mobile app space is great for everyone. But some part of me also kind of wishes that rather than spreading so much development effort out over so many mobile apps, that more developers would jump in and contribute to polishing up the official open source Lemmy mobile app, Jerboa. I can’t help but feel that it would be nice to see a focused effort somewhere in bringing that one in particular up to snuff, as a sort of “reference” app. And have a few others floating around out there just for some diversity and testing innovative ideas.
Maybe it’s already that way, I don’t know. It kind of feels like there’s a new Lemmy mobile app announced every couple of days.
However, that’s come with other tradeoffs in useability, speed, and fediration experience.
Like what? If properly configured none of the things listed should negatively impact hosting a Lemmy instance.
sure I’ll be adding an exception/rule for that, but it’s not a straight forward task.
It honestly should be to someone who would be hosting any public web application using Cloudflare. Cloudflare makes all of this quite easy, even to those with less experience.
Heck, the removal of websockets will require quite a few changes in my Cloudflare config.
What config are you referring to? In the Cloudflare console? For websockets changing to a REST API implementation there should be nothing at all you need to do.
Sure, someone truly concerned with security knows to do this, but that’s definitely not going to be everyone
And it shouldn’t have to be everyone, only those who take on the responsibility of hosting a public web application such as a Lemmy instance.
No matter the capabilities inherent in what you choose to host, the onus rests on the owner of the infrastructure to secure it.
Everyone should be free to host anything they want at whatever level of security (even none) if that’s what they want to do. But it’s not reasonable nor appropriate to expect it to be done for you by way of application code. It’s great if security is baked in, that’s wonderful. But it doesn’t replace other mitigations that according to best practices should rightfully be in place.
There’s nothing stopping instance owners from incorporating their own security measures into their infrastructure as they see fit, such as a reverse proxy with a modern web application firewall, solutions such as Cloudflare and the free captcha capabilities they offer, or a combination of those and/or various other protective measures. If you’re hosting your own Lemmy instance and exposing it to the public, and you don’t understand what would be involved in the above examples or have no idea where to start, then you probably shouldn’t be hosting a public Lemmy instance in the first place.
It’s generally not a good idea to rely primarily on security to be baked into application code and call it a day. I’m not up to date on this news and all of the nuances yet, I’ll look into it after I’ve posted this, but what I said above holds true regardless.
The responsibility of security of any publicly hosted web application or service rests squarely on the owner of the instance. It’s up to you to secure your infrastructure, and there are very good and accepted best practice ways of doing that outside of application code. Something like losing baked in captcha in a web application should come as no big deal to those who have the appropriate level of knowledge to responsibly host their instance.
From what this seems to be about, it seems like a non-issue, unless you’re someone who is relying on baked in security to cover for your lack of expertise in properly securing your instance and mitigating exploitation by bots yourself.
I’m not trying to demean anyone or sound holier than thou, but honestly, please don’t rely on the devs for all of your security needs. There are ways to keep your instance secure that doesn’t require their involvement, and that are best practice anyways. Please seek to educate yourself if this applies to you, and shore up the security of your own instances by way of the surrounding infrastructure.
It may make things simpler for the user, but at the cost of storage and performance of every instance in the index, which won’t scale well as more instances are added over time. I personally think it’s better the way it is. As long as you are educated enough to know how to federate with other instances you choose to federate with, you can keep your own instance minimally connected to only the instances and communities you actually care about.
Maybe a good compromise would be for such an idea as a globally replicated index, to be optional, so individual instances could keep it disabled if they wanted to. If you choose to enable it as an instance owner, the pain points for your end users go away, at the cost of performance and other potentially negative side-effects. If you choose to keep it disabled, you can still federate with any instances you want, but you won’t participate in the index. Or maybe your instance would be listed and replicated to other instances’ indexes, but your own instance won’t receive updates as the global index continues to grow. Since it would just be for convenient discoverability, there’s not really any problem with that. No functionality would be lost for your or any other instance.
The only thing keeping me from using it as my only file explorer is the fact that it doesn’t support SMB shares.