DevOps as a profession and software development for fun. Admin of lemmy.nrd.li and akkoma.nrd.li.

Filibuster vigilantly.

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

help-circle


  • Nope, not from a DNS level. All the posts you are reading are cached by whatever instance your account is on. Basically the only thing served from the remote instance is full-size media uploaded to that instance. Even thumbnails are served from whatever instance you use. Mastodon/Akkoma/etc can be set up to even proxy full-size media for users, which is a feature I imagine will eventually make its way into Lemmy. Your best bet at the moment would be to find an instance that defederates those you don’t want to see (or run your own and do so yourself). I know “blocking” an instance is an often-requested feature, so that may end up a feature in Lemmy itself at some point.








  • First, it’s worth noting that ActivityPub is built on ActivityStreams which is in turn built on ActivityVocabulary. It is necessary to read all of these to have a full understanding of what the stuff in AP actually means. It is also worth reading up on LDN and JSON-LD as those are also used in the spec.

    I think you are right in AP being a bit more oriented toward social media in the vein of twitter or facebook and less like reddit, but really a lot of it comes down to how an AP implementing server interprets the objects it receives. I’m not sure if anywhere near this level of customization would be possible if everything spoke pure AP (which does have a client-server interface, not just a server-server federation interface) rather than your clients interacting with bespoke “lemmy” or “mastodon” or whatever APIs.

    As far as lemmy goes I think they may have extended the objects a little, as there is a lemmy NS included in results, which is what most implementations including big ones like Mastodon do to introduce new fields (such as content warnings in the case of Mastodon) to things like a Note. Lemmy adds info like postingRestrictedToMods, matrixUserId, and moderators.

    As far as objects:

    • A community is a Group.
    • A post is a Page with an audience of the community and an attributedTo of your user (to the community and special public endpoint).
    • A comment is a Note that is inReplyTo its parent (post or comment), to the special public endpoint and CCing the author of the parent and the community.

    As far as actions, I am less sure because it is less easy to inspect without reading the lemmy code or setting up something to get federated to, but AFAICT:

    • Upvotes and downvotes are Like and Dislike
    • Create is used when you as a user want to make a post in a community
    • Announce is used when a post actually gets made in a community
    • I think Announce is used for other things and might explain some of how comments work as well, as a post seems to live on the community instance but a comment seems to live on your instance.

  • Every time you visit any website someone will know your IP address. Unless very specific measues are taken that “someone” will be whoever operates that website.

    Lemmy has features (I think they are optional) that will tell you that you viewed a post and how many new comments a post has from the last time you viewed it, that necessarily requires tracking. I cannot say whether turning this feature off disables the tracking or just doesn’t show you that information without digging into the code, this is only local to your instance.

    There is also likely to be some level of logging at the server and any reverse proxy layers that could, with effort, be used to figure out what you looked at with reasonable accuracy. Again, this is only on your instance. Some instances may not create/store logs, but it is usually important to do so to troubleshoot if things go wrong, especially with as immature a software project Lemmy is.

    Any time you visit a website you are putting a large amount of trust in the site operator, your ISP, your DNS provider, etc. if state actors are in your threat model.

    If you run your own instance you have better condom of this, and the only thing potentially externally observable is that a post has been sent to your server. Also, you should run your own server anyway.





  • There are a few completely fair points in there calling out what they are legally allowed to do (e.g. they are not directly violating GPL) and are doing (contributing changes back upstream, they claim “always”), that’s about the only “right” this reader found.

    Have some quotes that demonstrate the “wrong”:

    I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.

    Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make.

    Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity.



  • I think this is a problem with specifically how Lemmy is designed, how ActivityPub works in the browser, and how Lemmy is deployed. The issue should be entirely contained within Lemmy’s nginx layer unless your second LB is doing some sort of mangling to the request (changing the request’s Accept header, method, or path).

    The design of Lemmy is that there is a “lemmy-ui” component that is responsible for generating HTML pages, and a “lemmy” component that is responsible for everything else. “lemmy-ui” communicates with “lemmy” to make API requests so it can build the necessary pages. Separating these things out makes a certain level of sense, and allows them to be developed independently and even replaced with alternate implementations if necessary.

    Based on sniffing (Accept header) the request needs to either route to “lemmy” or “lemmy-ui”. The path and method based requests are fairly easy to handle as there isn’t ambiguity, if it is for a child of a certain path or it is a certain method (e.g POST), it always goes to “lemmy”. Things are more complex for GET requests for a comment/post because users will load that URL in their browser expecting HTML (which “lemmy-ui” is responsible for). Bots/federation/API clients will request that same URL with basically only the Accept header being different and expect JSON-LD (which “lemmy” is responsible for).

    The problem comes when you deploy such a system, you need some way to conditionally route certain requests to one service and certain requests to another. Lemmy has chosen to use nginx with manually maintained nginx.conf files.

    The options as I see it are:

    1. Build a system to generate the right nginx configuration when the proxy container starts. Something like it taking optional environment variables to define the hostname/port of the “lemmy” and "lemmy-ui, and it spits out basically what is in the repo right now but customized for you. If you need something more custom you’re on your own with that still being able to serve as a starting point ,but you probably not even using that container.
    2. Remove nginx entirely and set up “lemmy” to forward requests it thinks are by web browsers to a URL for the UI you can specify. (This may be problematic as it technically makes “lemmy-ui” and “lemmy” co-dependent, though whether “lemmy-ui” should expect to communicate with “lemmy” over anything but your instance’s public address is another issue entirely…)
    3. Remove nginx entirely and set up “lemmy-ui” to forward requests that look like backend requests to “lemmy”.

    I like option 2 best, as “lemmy” does something similar for “pictrs” already, though it is a little counterintuitive for what I consider to be the “backend” to forward requests to the “frontend”.


  • Yeah, I think you were spot on in your diagnosis of that particular error in your updated OP of needing to update-ca-certificates. As far as I can tell based on that podspec you aren’t really doing anything particularly odd that I would expect to break DNS or something at the network layer.

    Is the issue you are seeing in your logs any different now, or still the same as before the ca certs?


  • I would start by kubectl exec’ing into your pod and using nsllookup/dig/whatever you have available to check whether DNS resolution is working inside there at all. I don’t think there is an easy way to break DNS resolution via config without it being pretty clear that you’re doing so, but you could try messing with the pod spec’s dnsPolicy (I often end up using ClusterFirst) and dnsConfig.

    I may be able to help more if you post your pod spec.


  • I think a lot of this comes down to an inherent problem with using the same protocol and objects to represent different things. In Lemmy users send a Create (of a post or comment) the instance that houses the community and the community sends an Announce to subscribers/followers of that community because it is a thing they care about, Mastodon interprets that as a “Boost”. Lemmy uses “Like” and “Dislike” for votes, which turns into a “Favorite” and (nothing?) on Mastodon. Lemmy uses Links not Notes because Lemmy is a link-aggregator that just happens to have the ability to link to a text post on lemmy itself.

    I think there are some attempts at a more “universal” interface into the fediverse where you can choose to see a threaded/nested view like Lemmy or a stream-oriented microblog like Mastodon. At the moment there is no real solution as far as I can tell.