If you’re taking that approach make sure you shut down the stack before you copy the data over so everything gets copied over consistently (e.g. the DB isn’t in the middle of a write), and yes it should pretty much be that easy.
DevOps as a profession and software development for fun. Admin of lemmy.nrd.li and akkoma.nrd.li.
Filibuster vigilantly.
If you’re taking that approach make sure you shut down the stack before you copy the data over so everything gets copied over consistently (e.g. the DB isn’t in the middle of a write), and yes it should pretty much be that easy.
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.
Posts will make their way over when someone interacts with it (comments/votes on it). I think old comments may make their way over under the same conditions. Old votes will not make their way over.
You can search for a post or comment to force your instance to load it (copy the federation link, the rainbow-web-looking icon) just like you would do for communities.
I’d be glad to help. The more people actually run their own mail the harder it gets for the big players to shut us out, haha.
Yeah… they really shouldn’t be shipping that mail relay at all IMO, just leads to confusion.
I do run my own mail and assuming it’s reasonably low volume would be more than happy to get you set up to use my mailserver instead of relying on something like sendgrid or postmark.
Alternatively if you want some help getting your own set up in a dockerized way I run my mail using docker-mailserver and if only set up for outgoing mail it is pretty easy to run, though you may will run into deliverability issues…
It looks like you aren’t signing your mail with DKIM, don’t have SPF set up right, don’t have a DMARC policy, and don’t have RcRDNS, all of which basically any mail provider will require from you to even consider accepting your mail. Basically without all of that literally anyone can pretend to be whatever.com
and send email from it.
What mail provider are you using?
I got an email when I signed up as a test. It is most likely spam filters and/or improper email server setup. I will try to help debug in a bit.
With the specific concern/idea you are talking about, I have suggested the use of a system like (or just ripping-off wholesale) the Mastodon Content Warning system in a discussion where someone was advocating a “porn” tag in addition to the NSFW one, which I thought was not going to be flexible enough.
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:
audience
of the community and an attributedTo
of your user (to
the community and special public endpoint).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:
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.
Seems like most of the Tesla shills haven’t really made it over to the fediverse yet, so that’s nice.
Ah yes, the ~50 year fad of SQL that has already survived its heralded death several times already will go away “because UNIX”. I think the article is a joke, but I can totally imagine certain people arguing this…
Unsure, some sort of 14.4kbps PCI modem that was very outdated when I started using it in my youth. We had broadband, but it was only for one machine and I was only allowed to use some random free ISP (NetZero maybe?) to keep my time on the internet limited or something.
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.
And make sure that identifier scheme still works if different people on different subscriptions download the source and compare to filter identifiers like that out…
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:
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.
No, these issues are pretty much by-design. In ActivityPub IDs are inherently tied to the domain on which they were created. Based on the nature of federation it is safe to assume someone somewhere will still go looking for that thing via the outdated URL.