Social Engineering for Good. Social Engineering for Progress.

AFAIK, “community migration” is done in PieFed by having the target instance making a request to the source one to change, and if the owner authorizes it then it PieFed recreates the actor and its objects on the target instance. Then it is up to the owner of the source community to delete close the source community.

My objection is to this recreation of the objects. If someone creates a post on “community@alpha” and the moderator decides to move to “community@beta”, history is being recreated and it makes “beta” with activity that is not original. Also, having the consent from the community owner is not enough, because it ignores the fact that the members of the alpha community might not be interested in being associated with beta.

I still don’t understand how this is not akin to falsifying data. If we normalize servers copying data from other instances and just rewriting the URL, there is little in the way for malicious actors to create piefed instances to scam others pretending to be someone they are not.

lemmy-federate is the wrong solution to this problem. It duplicates data on all instances, even those with no subscribers. it increases the load and the amount of storage requirements for small instances

What we need is a system where admins can set up a separate discovery service, and include that in search results. Mastodon is finally doing something in this direction, and Lemmy/PieFed/mbin would benefit a lot to adopt it.

I’ve added the “without any justification or discussion about the merit of issue at hand” as a qualifier…

It’s totally fine if you say “yes, this looks cool but I don’t have the time to do it”, or even “I’m not so sure about it, but if you bring a PR we can take a better look at it”.

Unless you are on a frantic hurry to make this change, I might be able to help. You’ll need to migrate to Wagtail, and I have done some work on integration with Wagtail and the Fediverse via the Django ActivityPub Toolkit. But if you do consider this, you’d have to keep in mind that the ActivityPub side of things would be a ongoing experiment.

projects like Garage allow to do so in a distributed way.

Really? Does this mean that different instances could share a bucket? Do they have to trust each other? I’ll have to jump off the minio train anyway, if you have any tips to get this going would be nice.

!sideproject@indiehackers.space also serves for that. Join us!

you are in control of which social media you use

I don’t use or support Bluesky.

You are currently spending your energy defending a company

I’m not defending anyone. I am just looking at a stated claim (Bluesky is as bad as Twitter because they verified ICE) and evaluating if it has merits. I don’t think it does.

If a newspaper you enjoy reading

The “newspaper I enjoy reading” is the WWW. The reason that I don’t buy newspapers is because I want to keep the power to curate the information that I receive. As long as I am reasonably in control of the information that I can access, I see no point in complaining about it.

If you want to make a parallel to Reddit: despite it being 99% filled with crap that I don’t care about, I could use it just fine and ignore all the drama. But when they decided to change the terms of the API and they were trying to force the specific channel to use to access it, then I immediately “stopped enjoying it” and went on to work on a solution to be back in control.

So, you would be OK with a newspaper accepting ads

What I am “OK with” has no impact whatsoever in “what actually gets to happen”. I rather not waste my energy on the things that I can not control.

Banning ICE would not let them post Nazi propaganda

It would. They would just do it from unverified accounts. Worse still, they would be able to post it and completely deny it if confronted about it.

the corporate overlords of bluesky will let them post propaganda for free.

Spammers also get to send millions of messages every day for “free”, but we mostly ignore it because we are able to filter them out. Sure, it would be great to completely get rid of spam and the phishing industry… but there is no way to completely get rid of them that does not involve increasing the surveillance aparattus and given more power to a centralized enforcer, so if I have to choose between spammers and corporate-controlled communicatioins, I will take the spammers any day.

I don’t know how else to say it: you keep falling into the same non-sequitur.

No, I don’t expect them to ban anyone from the government. And, no, I don’t think it would be wise to do it: verifying the account does not mean they are supporting it, it just means they are making sure that whatever crap ICE is saying can not go around without accountability.

If you don’t want to see their shitty posts, now you can simply filter it out. And thanks to verification, you can share your filters to others. That’s how decentralized systems work. Bluesky does not control who I get to see. ICE or any other institution can not buy its way into manufacturing propaganda. It’s not ideal, but it’s better than any of the existing alternatives.

but one implies that the other will not be done.

This is false.

Labeling the account as verified and excluding/not excluding from the AppView are two separate actions.

It’s a good thing they get verified. It means they can not take back anything they post and they have to take accountability for the account.

Do you think it would be better if they didn’t verify it and let them spread misinformation and propaganda with plausible deniability?

It could be an optional feature.

By default, users and communities share the namespace so they can not have the same name. But if you as an admin want to let users and communities with the same handle (the “as:preferredUsername”), then you need to add two CNAMEs that point to the same domain of the backend, and add these to lemmy.hjson, so that the backend can know how to generate actor ids.

Of course, this still wouldn’t let mastodon users to find the actors by querying “username@myserver”, but at least they would be able to know they can find “@username@people.myserver” and @username@groups.myserver".

But we are not going to get “niche” users if we don’t get large numbers of users. Niche interests will only come up here when the population is so large that even the long tail ends up with critical masses.

Those defending “quality over quantity” miss this exact point.

I think this is yet-another reason to have a separation between users and communities at the instance/domain level.

Setting up a server should require one top-level domain and two subdomains:

• https://myserver.com/ would be for webfinger and the actual backend.
• https://groups.myserver.com/ would be the subdomain for the AS2.Group actors
• https://people.myserver.com/ would be the subdomain for the AS2.Person actor

I sound like a broken record, but none of this would happen if the devs took a good look at RDF before throwing everything into objects/classes and ORMs.

I’m working on something that aims to be compatible with Lemmy’s API, and my models are based on the context definitions first. This means that it becomes impossible to have communities and users with the preferred_username, because they are both actors.

That might work, but it’s never a good idea to write your code against a specific implementation. Plus, it seems that in this case the Lemmy devs shot themselves in the foot: why allow to create two different types of actors with the same name?!

I am not so sure Mastodon is at fault, here. Going to https://lemmy.world/.well-known/webfinger?resource=acct%3Avinyl%40lemmy.world, this is the result:

{
  "subject": "acct:vinyl@lemmy.world",
  "links": [
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://lemmy.world/u/vinyl",
      "template": null
    },
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://lemmy.world/u/vinyl",
      "template": null,
      "properties": {
        "https://www.w3.org/ns/activitystreams#type": "Person"
      }
    },
    {
      "rel": "http://ostatus.org/schema/1.0/subscribe",
      "type": null,
      "href": null,
      "template": "https://lemmy.world/activitypub/externalInteraction?uri=%7Buri%7D"
    },
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://lemmy.world/c/vinyl",
      "template": null
    },
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://lemmy.world/c/vinyl",
      "template": null,
      "properties": {
        "https://www.w3.org/ns/activitystreams#type": "Group"
      }
    }
  ]
}

So, lemmy is just providing two different actors for the same subject name and saying they refer to the same account.