terribleplan

I think it would need to be a mechanism similar to how user moves are handled where the old thing sticks around forever but has a field that says “the new one is over here” and then the new one has a field that says “yes, I am the same as that old one”. At least I think that’s how e.g. mastodon handles moves of users (just the person/actor, not any of their content. AFAIK nothing in the fediverse can do something like this with anything other than a person/actor at the moment)

The problem is the thing has already been federated. Changing the ID in the db will appear to the rest of the fediverse as new things, not as those same things.

Pretty sure it needs to be https://$user:$pat@github.com/username/repo.git#branch.

I would still go with one that isn’t one of the biggest. My general advice is to find one that fits the vibe you’re going for, communities you’re interested in (e.g. some are focused on art or cybersecurity, etc), or is somehow tied to your locality. It shouldn’t matter that much, though some servers will be a little more (or less) strict with things like federation, content warnings, alt text, etc. Usually the server will have some info telling you some of this, and their admin should be linked and likely has a post or two pinned to their profile explaining some of this as well.

I am partial to kind.social, though have opted to run my own instead of joining up anywhere.

It depends on what specific thing you want to add geoblocking to, but often something like the MaxMind GeoIP database, which then can feed into a firewall to pre-emptively geo-block at a connection level, or as part of e.g. nginx geolocating the IP a of the connecting IP then making the blocking decision at request time.

There’s a project that works with Traefik’s forward-auth middleware to do this, which is probably how I would go about it if I wanted it at an HTTP level.

Things don’t get backfilled, so until a new action happens on an old post/comment/etc they won’t show up on your instance. New things should make their way in eventually though.

Taking the link of a specific post/comment from the community instance and searching for it from your instance should populate it on your instance, just like you probably had to do to get this community to show up so you could subscribe/post at all.

There are backfill tools/scripts, but unless you really want old posts I wouldn’t use them. It unnecessarily increases the load on already struggling popular/overloaded instances like lemmy.world.

Not sure if it’s relevant as pretending to be form Germany may be the point here, but “Tor clients” aren’t “from” anywhere you can know, that’s just where the exit node is located.

I know that is an often discussed and requested feature, but as of right now there is no import/export as far as I am aware.

It can cause some wackiness… basically you will need to maintain that old domain forever and everything will still refer to that old domain.

For example, your post looks like this from an ActivityPub/federation perspective:

{
    [...]
    "id": "https://atosoul.zapto.org/post/24325",
    "attributedTo": "https://atosoul.zapto.org/u/Soullioness",
    [...]
    "content": "<p>I'm curious if I can migrate my instance (a single user) to a different domain? Right now I'm on a free DNS from no-ip but I might get a prettier paid domain name sometime.</p>\n",
}

The post itself has an ID that references your domain, and the the attributedTo points to your user which also references your domain. AFAIK there is no reasonable way to update/change this. IDs are forever.

It would also break all of the subscriptions for an existing instance, as the subscriptions are all set to deliver to that old domain.

IMO your best bet would be to start a new instance on the new domain, update your profile on the old one saying that your user is now @Soullioness@newinstance.whatever and maintain that old server in a read-only manner for as long as you can bear.

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…

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…

Users are empowered to set what they want their default homepage view to be (“Subscribed” , “All”, or “Local”). I am unsure what the default is, but mine is set to “Subscribed” which I think it makes the most sense for most users.

Unless you are on a heavily moderated/defederated server (such as beehaw) whose moderation policies, politics, etc. you are aligned with it is very likely that “All” is going to contain something that someone doesn’t like. I am personally not in favor of over-policing what users do outside the confines of their home instance, it’s a fine line that I haven’t had to define too clearly yet so perhaps my thoughts here will change.

If you don’t like what’s in “Local”, then to me that is a sign that the instance isn’t for you. Local is a reflection of the sort of content that users on that instance want to see more of. The admin allowing such content is not necessarily an endorsement (unless they were the one to actually post it), but is tacit acceptance of that content and the community that content exists in.

I think some way to make a “Curated” feed of posts only from certain approved communities would be a welcome feature and present a useful middle ground allowing for a moderatable discovery experience, like the default subscriptions provided on that other site.

My first thought when you mentioned those issues with Jerboa and comments was websockets. This is how the lemmy devs configure nginx, and I would make sure your setup on OPNSense is similar, specifically the “Upgrade” and “Connection” header bits.

If you want L3 features you want a router, not a switch. </pedantry>

Perhaps I am a unicorn, but I have self-hosted my email for years and don’t have deliverability problems. The only problems I have had:

1. I think I had to sign up with some sort of Microsoft thing or submit a ticket to them or something because I had an issue with sending mail to o356. That was resolved quickly and I haven’t had a problem since.
2. My server host (Linode, and Digital Ocean before them) is on the UCEPROTECT-L3 blacklist, because they (and whitelisted.org) are a bunch of scammers and block entire ASNs for almost any amount of spam, then extort individual mail server operators to get their IP specifically delisted.

To me one of the big things that differentiates Lemmy (and the fediverse in general) from email is that most of it is public, so the things in email that would involve sharing someone’s private information (email addresses, IPs, email contents, etc) are public (at least the post/comment and username+instance), and can all be verified. I think there is a lot of potential because of this. Maybe I’m crazy, but I just really don’t like the idea of a whitelist-based system because it means I as a small instance operator may have to sign up to dozens of services like the one you are building. I want my instance to be able to federate pretty much as widely as possible, and to me such a burden is too much to ask within a system/protocol/fediverse that is designed to facilitate sharing and decentralization.

Also, I think there is already room for a problem with “capture”. What motivation is there for .world .ml or beehaw to bother signing up for your thing? Even assuming you get 100 like minded admins to sign up for Overseer that is probably a pretty small fediverse island without them, some or all “mega” instances will probably just end up getting a pass anyways and at the end of the day no system is in place to help with the problem of bot/spamming users on trusted instances (whether in that WoT or just blindly trusted by the WoT).

Most of the spam I get is from gmail addresses, I don’t see it going any differently here.

I agree that we need far stronger admin and moderation tools to fight spam and bots. I disagree with the idea of a whitelist approach, and think taking even more from email (probably the largest federated system ever) could go a long way.

With email, there is no central authority granting “permission” for me to send stuff. There are technologies like SPF, DKIM, DMARC, and FcRDNS, which act as a minimum bar to reach before most servers trust you at all, then server-side spam filtering gets applied on top and happens at a user, domain, IP, and sometimes netblock level. When rejections occur, receiving servers provide rejection information, that let me figure out what is wrong and contact the admins of that particular server. (Establish a baseline of trust, punish if trust is violated)

A gray-listing system for new users or domains could generate reports once there is a sufficient amount of activity to ease the information gathering an admin would have to do in order to trust a certain domain. Additionally, I think establishing a way for admins to share their blacklisting actions regarding spam or other malicious behavior (with verifiable proof) could achieve similar outcomes to whitelisting without forcing every instance operator to buy in to a centralized (or one of a few centralized) authority on this. This would basically be an RBL (which admins could choose to use) for Lemmy. This could be very customizable and allow for network effects (“I trust X admin, apply any server block they make to my instance too” sort of stuff).

I think enhancements to Lemmy itself would also address help. Lemmy itself could provide a framework for filtering and report when an instance refuses a federated message with relevant information, allowing admins to make informed decisions (and see when there are potential problems on their instance). Also having ways to attach proof of bad behavior to federated bans at an instance level, and some way to federate bans (again with proof) from servers that aren’t a user’s home instance.

Finally, as far as I can tell everything following a “Web of Trust” model (basically what you are proposing) has struggled to gain widespread adoption. I have never been to a key signing party. I once made a few proofs on keybase, but that platform never really went anywhere. This doesn’t mean your solution won’t work, it just concerns me a little.

I expanded a bit more on some of how email tooling could be used within lemmy in this comment as well. My ideas aren’t fully baked yet, but I hope they at least make some sense.

Yeah, as I said IDK what device timelines are, but for some reason I can’t imagine apple not releasing an iPhone in the EU for 4 years… the charge port mandate was not super impactful/difficult for Apple to comply with. I am still not convinced Apple isn’t going to drop the charge port entirely in favor of their magsafe wireless thing (again, anti-consumer IMO), or at the very least will be putting out an EU-only SKU with USB-C.

2027 seems kinda weak sauce. Maybe it is more reasonable than I feel given I don’t know much about hardware design timelines, but I honestly was hoping for more of a middle finger to companies that have embraced the anti-consumer practice of using non-replaceable batteries.

Lol.

- Sent from Firefox Browser