Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@eniko @igimenezblb Thinking about it a bit more, that's already kind of implied in the 'learned' part of 'learned helplessness' so I'm not really sure now where this apparently widespread belief of it being 'human nature' comes from 🤔

@eniko @igimenezblb I don't think that's some kind of fundamental human nature though, rather a result of the experience people have had through their lives (which, let's be real, haven't exactly featured particularly much agency over the shape of their own lives)

@q A big deal is made about them mostly because of the governance issues surrounding their introduction, but while their design does imply a lot of internal changes in Nix, flakes *themselves* are a fairly simple concept:

They're like a sort of package.json for chunks of Nix code. A manifest with a standard-ish structure for exporting different kinds of things in predefined ways, where you can make certain assumptions about it, so that you can build a bigger whole on top of it.

That's really all it is. Everything else is internals changes to make this actually work in practice, but this is the fundamental problem it's meant to solve, a standardized declarative way to export and reuse piles of Nix without having to centrally manage everything in one repo or deal with 5 slightly different sets of import/update semantics.

@virtulis The 'not converging' is a problem there, unfortunately - the authorization process is emergent from the state convergence, and so different parties would have a different view of authorization rules.

@tante This is exactly the same thing I've noticed as well (this phenomenon has pretty much taken over the JS world since the startups rolled in during a hype cycle), but frustratingly we now seem to be looping back to "don't use other people's code ever" instead of people actually critically asking themselves whether maybe it's the *type* of dependency that's the problem 🙁

@virtulis (I'm still looking into your suggestions, by the way, it just takes a while to absorb all of this properly)

@joelving I guess a more succinct summary of my point would be that "decentralization" is a catch-all mechanism for a pretty broad set of social and technical properties, and often people want some but not necessarily all of them.

@joelving That's true to a degree, but not entirely - for example, enabling reply controls on a post means you centralize the control over who can participate in that conversation, but it doesn't imply that it is therefore acceptable for the conversation to become inaccessible to everyone if the OP's server has an outage.

There's a distinction to be made here between whether something should be *conceptually* decentralized versus whether it should be *technically* decentralized, and those aren't always going to have the same answer. In the cases where they don't, the challenge is precisely in finding a way that gets you both answers. (At which point "centralized control on a decentralized system" is usually easier to implement than "decentralized control on a centralized system".)

@joelving There are some pretty severe accessibility implications in this, unfortunately, unless you are *extremely* careful about how you approach it (at which point it starts looking more like what we have now).

Likewise, you lose a lot of technical resilience - which isn't actually that important on a technical level, but *is* important in terms of making it Not A Big Deal when something goes down, which is in turn a big factor in making decentralized things sustainable at *any* degree of decentralization.

That's not to say that these can never be acceptable tradeoffs, but they are tradeoffs that need to be made very deliberately, compensated where possible, and with a very good understanding of what it gives and takes to and from whom.

There are some things for which the model you're suggesting makes much more sense than the AP model; code forges and community platforms, for example. These usually have a distinct 'home' and so decentralization on a protocol level doesn't matter much, and identity is really the only relevant factor. I don't think AP is that useful in Forgejo for example.

But for something that's trying to basically do emergent communities in a global shared Twitter-esque space, like Mastodon, I'm not sure that centralizing interactions onto servers would still be worth it once you reason through all the less obvious implications that it has.

@silvermoon82 The only annoyance is that I do not enjoy time arithmetic, but I've concluded that it's a small price to pay for never having to deal with Software(tm) to get paid

@silvermoon82 (Have been using this for like 4-5 years by now, clients who want timelogs seem to be happy with just receiving a .txt in this format as an attachment, and it gives me arbitrary space for adding notes and inventing new notation as needed for weird cases)

@silvermoon82 Literally a text file as a ledger 🙃

hours.txt, three-line entries with a date, starting time, end time, and the second line contains a comma-separated list of stuff I've done, then afterwards I tally up the hours worked and make that the third line, stating '$workedTime -> $runningTotal'.

Only option I've found that doesn't actively frustrate me about people's bad UI design while trying to get work done.

@virtulis For the hash thing I have a specific concern: wouldn't this be a problem for *partial* partitions? If node C partitions from node A but not from node B, then node B might have a dfiferent idea about what node C's last mutation was, even though it was a legitimate partition, right?

This could presumably be solved by sharing a *log* of hashes but that seems like it would get pretty bandwidth-intensive pretty quickly.

For the vector clock scenario: that seems like a possibly viable avenue to explore with some modifications (like enforcing sequential submission of mutations from any given server, though that rules out mesh routing of mutations as a resilience improvement), but it does seem pretty complex to implement in a scenario where the set of participants can change significantly over time, and in this scenario it's actually credible that one might burn a node on a single backdating event 😐

@azonenberg (What complaints about Electron usually overlook is that Electron doesn't actually use any meaningfully large amount of resources, and the resource use of Electron applications likely has much more to do with the background of the developers working on them than with the tech stack)