Hard to say. That’s the problem.

A detectable bot problem is a solvable bot problem.

Not from an ASCII

Then the identity still has a home.

I’ve implemented Oauth and you still have an identity provider.

The vast majority of people who use lemmy have not read the activitypub protocol, and signed up to use lemmy as it exists today

Identity belonging to an instance, changing to identity belonging to the fediverse as a whole.

Identities containing @instance format.

Identities being federated.

At a more abstract level, inviting a bunch of people to play a game, and then changing the rules of the game, is a shitty thing to do.

The fediverse has rules built into it. It has a way that it works. Changing that makes it something else.

Maybe failover identities that consume the primary identity’s activities as a log. The failover identity (let’s call them jump clones for fun eh?) can be stood up as primary if the primary goes down (gets banned, instance dies, etc)

My potential argument against it starts with asking where the credentials are stored for authenticating this identity.

Currently the home instance stores the hashed password and performs authentication.

In a way, the identity “belongs to” the place that does authentication, which now happens to be the instance.

If identity is decoupled from an instance, that means authentication decouples from an instance.

If the identity “belongs to” the fediverse as a whole, then that means the fediverse as a whole has an authentication mechanism.

Unless we can come up with a distributed authentication mechanism, that means the fediverse as a whole has some authentication service, as in one, which means centralized.

This therefore breaks decentralization, unless the authentication is somehow handled in a distributed way. Maybe consensus or something on a hashed password? But if those hashed passwords are stored in a distributed manner, then you’d need a super long password to prevent rainbow table attacks on the passwords, given the hashed values would essentially be public information.

Maybe public keys are stored in a blockchain? I don’t know this is beyond me in the details.

But to summarize the problem at a data model level, an identity belongs to an instance, because the instance can authenticate them. If the identity now belongs to the whole fediverse, then the whole fediverse needs to be able to authenticate them, which if not handled correctly could lead to centralized authentication, centralized banning, censorship, reddit, etc.

Activitypub can include private messages

And people like me who don’t go away just because they get downvoted.

You can go find your community of all positive interactions, and well keep our positive/negative mix.

Would a dinner party suffer if it had 10,000 people at the table and instead of saying “shut up” people could just turn the volume knob down on someone else a little, but nobody’s voice would get silenced unless more people turned the knob down on them than up?

What if the dinner party were open invitation?

Downvotes fold comments and sort them last. It’s signal inhibition.

Maybe

If they can’t be articulated, I lose respect for those reasons

Not with that list we’re not

Why do we need to have a unicode character that refers to the fediverse?

Are we trying to replace our alphabetical language with a language of ideograms?

Holy shit we are bloods

So we’re Bloods now?

Not sure if you’re missing this or deliberately ignoring it, but I don’t know how monero does it. That’s why I’m just saying “in the same way they do it”.

The application I am thinking of is:

• Verify that someone has legitimately
• Used voting power they possess
• To assign value to a particular account
• Without revealing the identity of the “someone”
• In a way that can’t be faked

In monero, the “voting power” is the ability to transfer funds to a particular payment address.

In lemmy, the “funds” are votes and the “payment address” is a comment or post.

You could actually implement such a content voting system using monero, if everyone were willing to put in a couple cents’ worth of monetary value. You’d just generate a pair of payment address for each vote target, one for upvotes and one for downvotes.

You’d have to use another layer of software for generating all these payment addresses, and that software would have to be trusted as well, but basically for any possible combination of voter/voteDirection/voteTarget you’d generate a payment address. As soon as funds appear in that payment address, the vote has been cast.

That’s just a hack knowing nothing about how monero actually accomplishes that. That’s using monero as an engineering black box, without knowing how it works.

I would not have asserted that there is no way to make such a payment system, based on the same instinct people are basing the judgment that such a voting system cannot be made. But I’d be wrong, because monero exists and works, and so this tells me the same problem can be solved in voting.

How would it work?

Like monero. However monero does it is the strategy I propose.

why?

For the same reason it’s not readily available already.

Man I would have assumed that information would be cryptographically obfuscated while still being verifiable, like monero.