@evan the "2023 Israel–Hamas war Part of the Israeli–Palestinian conflict Part of the Arab–Israeli conflict Part of the Cold War (1956, 1967–1991)" per English Wikipedia, complete with en dashes.
Curiously since the above war is not within the territory of the former USSR it isn't post-Soviet, thus the non-overlapping years, cf
"Russian invasion of Ukraine Part of the Russo-Ukrainian War Part of the post-Soviet conflicts"
Wow no en dash in those names. Surely there have been massive edit wars
@evan I'd E-ncapsulate it. Speaking with extreme naivety, but that is to say with this half-baked allusion, rooting for whatever I imagine @spritelyinst might be cooking up.
@n8@clacke@petrichor@liw@idlestate that's OK, I'm idly interested in the topic. FWIW @danielskatz is someone to follow who is deep in the field (and Daniel's posts are mostly relevant, and show others to follow).
Among crowd getting away from what a short while ago looked like a potential battle in Rostov, person making a weird fashion statement and/or fan of @rasmusfleischer?
@clacke do you have an existence proof of FastSafeLang ⊆ SquishyLang?
I don't see how that works.
Seems to me that types and eg more control over memory requires more not less of a language, so (after seeing Mojo and reeading @mpweiher's blog) FastSafeLang ⊇ SquishyLang is possible, and seems natural.
@aeva right! Nevermind fediverse servers, it's always been amazing to me that web apps in general haven't taken this path. But, has to be designed for, evidently a huge barrier.
@clacke@aeva I'm unfamiliar w/those but C web server exposing low level scripting interface semi-popular forever eg Navi/Tcl, Netscape/js, Apache/mod_*, I guess ngnix/Lua now. Definitely thinking of pushing FastSafeLang impl up to ~framework level, with scripting for only application-specific code. Figure it's a naive thought though considering unpopularity to say the least.
@fu probably coincidental as it looks like you use it frequently, but good use of ♲ here anyway. IIRC it was common to use ♲ for "redents" before StatusNet supported them directly, since "RT" was from Twitter (though some used it anyway) and "RD" seemed to be missing something.
@tarkowski for the fediverse in particular I'm semi-convinced (semi- because I don't understand well enough & would love to be wrong) that the technical underpinnings are such a limiting factor that governance at whatever level (other than that which results in speeding up technical improvement, so cheering things like @spritelyinst) is not going to make a big difference toward ends such as more autonomy for people and communities globally.
@tarkowski and I'm definitely not against more participatory gov. Closely held decisionmaking (whether by a would-be benevolent designer, foundation, or [too numerous to really even consider] company) often rankles users and arguably results in worse software/community/other result. Quoting and Mastodon may be an example. Lots of arguable issues stemming from this with eg Mozilla, Wikimedia, GNOME. But novel governance also costly (including risky), so I don't advocate simply for more of it.
I agree not knowing how to migrate between instances, particularly those running different software, is a big problem. Idle thought/wish, maybe @DTinitiative will intervene; probably few fediverse software designers wish to prevent migration, but making it work great is also work not at top of any of their priorities, probably.
@tarkowski I feel really uneasy about analyzing a model based on a label -- unfortunate word choice from when cheeky wording was stupidly deemed internet cool. Replace with "designer" for cooler analysis. Then it should be obvious that "it should be obvious" needs fleshing out! ?
I idly wonder if Mastodon project (or mastodon.social, I thought interesting what Rochko said about default instance in interview) is most important participatory fediverse governance venue. Open question in my mind.
@tarkowski think for a minute, it's *extremely unlikely* Rochko "is thinking about Mastodon as just a piece of open source code that needs to be produced" not realizing "the code is just a tool for a social network, that is shaped with software tools. Allowing quotes of posts is not a decision about code - it’s a decision about how millions will comunicate."
Please, advocate for and better explore participatory governance, but start from higher and factual ground.
Given how uncool so many URIs have proven to be, I'd want any additional instructions to further the "don't change" mission. Hmm, wonder what those would be, interesting challenge!
Is there any reason to think a URI having an inbox or being subscribable would be more likely to not change -- or more likey to change?
I do think a similar doc, perhaps w3.org/Provider/Style/Social would be...cool!