• 0 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: June 5th, 2023

help-circle





  • I use Clipious, an Android client for Invidious, on my phone. I selfhost my own Indivious instance so this is perfect in that my phone never connects to YouTube directly, and I can save all my subscriptions in one place without a YouTube account.

    On my Android TV I use Smart Tube Next. If I really need to cast, I also have YouTube ReVanced on my phone for just that, but I barely use it.

    As soon as Clipious gets a proper Android TV interface, I’ll be set, as both devices can just connect to Invidious and let it do all the work.




  • 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’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’ll update to a newer Postgres version and report back. It would be nice to know what the minimum supported version is, maybe that should be added to the documentation.

    EDIT: Upgrading to Postgres 15 resolved my issue, but not without some pain since the migration scripts had already tried to run on my Postgres 13 database. So after dumping the 13 database, I had to make some modifications after the fact to satisfy the migration scripts. It was a pretty janky process but I seem to be in a good place now.

    I would highly advise communicating to people that they should upgrade past Postgres 13 before trying to upgrade Lemmy to 0.18.3 or higher, or you’re gonna have a bad time.




  • wpuckering@lm.williampuckering.comtoFediverse@lemmy.worldwtf is happening?
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    16
    ·
    edit-2
    1 year ago

    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.



  • There’s a lot of things that factor into the answer, but I think overall it’s gonna be pretty random. Some instances are on domains without “Lemmy” in the name, some don’t include “Lemmy” in the site name configuration, and in the case of some like my own instance, I set the X-Robots-Tag response header such that search engines that properly honor the header won’t crawl or index content on my instance. I’ve actually taken things a step further with mine and put all public paths except for the API endpoints behind authentication (so that Lemmy clients and federation still work with it), so you can’t browse my instance content without going through a proper client for extra privacy. But that goes off-topic.

    Reddit was centralized so could be optimized for SEO. Lemmy instances are individually run with different configuration at the infrastructure level and the application configuration level, which if most people leave things fairly vanilla, should result in pretty good discovery of Lemmy content across most of these kinds of instances, but I would think most people technical enough to host their own instances would have deviated from defaults and (hopefully) implemented some hardening, which would likely mess with SEO.

    So yeah, expect it to be pretty random, but not necessarily unworkable.


  • I run all of my services in containers, and intentionally leave my Docker host as barebones as possible so that it’s disposable (I don’t backup anything aside from data to do with the services themselves, the host can be launched into the sun without any backups and it wouldn’t matter). I like to keep things simple yet practical, so I just run a nightly cron job that spins down all my stacks, creates archives of everything as-is at that time, and uploads them to Wasabi, AWS S3, and Backblaze B2. Then everything just spins back up, rinse and repeat the next night. I use lifecycle policies to keep the last 90 days worth of backups.