Sven Slootweg @joepie91@pixie.town

For clarity, most of these comments I'm talking about weren't actually directly *on* fedi, but rather linked from here.

Not a subtoot of anyone directly here, but since it's coming up again, and some of the claims I've seen are getting rather bizarre: yes, the guy is probably a bigot, yes, I wouldn't trust him either, but do please remember that not everyone lives in the US and different places have different cultures.

This doesn't *excuse* bigotry, obviously, but it is vitally important to understand the cultural background of someone to fully understand the context or perspective from which a comment is made, and some of the comments I've seen on the topic seem to be assuming that everyone is somehow magically aware of (and shares) the cultural context and norms of the US.

(And it's worth asking yourself whether making that kind of assumption is not just another aspect of cultural imperialism...)

As a sidenote, this is why I don't engage on discussions about "but people need a way to make a living!" if the speaker isn't willing to acknowledge that that can also very quickly become a problem if you're not super careful about how you implement it.

Like, we've tried just implementing "letting people make a living" directly. That's how we got Bitcoin.

https://blacktwitter.io/@thiswomanswerk/113368795659069245

2009 decentralization discourse: how do we create financial incentives, so that the network survives?

2024 decentralization discourse: how do we *keep out* the financial incentives, so that the network survives?

And once again, the only actually useful article I could find on a math/crypto concept was one that openly rants about every other article being impenetrable garbage with unnecessarily obtuse mathematical notation.

Every fucking time.

I have a difficult protocol design problem that I need some suggestions for to explore. Please read the requirements carefully because they are very specific, and leave the "it's impossible" comments at the door, because I *know* that this is a seemingly impossible problem already.

(The problem description is also intentionally generalized and reduced down to its core mathematical problem, to avoid unintentional assumptions.)

I have a distributed protocol. The different parties involved mutually distrust each other. They can each contribute mutations to a shared state log, based on some unspecified authorization algorithm which allows for revoking access of other parties. The parties eventually converge onto an identical view of the state, though temporary partitions may occur.

The problem is that a genuine partition followed by a delayed delivery of mutations, seems indistinguishable from a malicious attempt at subverting an access revocation through backdating of mutations.

In both cases, one or more mutations are received which are dated to a timestamp that was potentially a long time ago, and that may be working off an old version of the state.

There is (currently) no shared clock, and there is a small but non-zero span of time between the most recent accepted mutation from a revoked party, and the actual revocation of their access.

How do I prevent backdating, without losing resilience to partitions?

I'm not necessarily looking for full-blown solutions (though those would be welcome!), but even just pointers on relevant research would be welcome, as long as it is research that accounts for all the properties here: untrusted parties, no shared clock, exploitable timespan before revocation.

By the way, I hope this didn't need to be said, but never buy "backlinks", doesn't matter from where. It means you're paying for a spammer's linkfarm. Even if they look legit on the outside.

Oh hey, I ran across one of those companies that runs a shitty linkfarm for spamming search engines, unsurprisingly they call themselves a "SEO" company, seem deeply embedded in the SEO community, and are talking about ChatGPT/"AI" use for SEO