Now I feel the curious itch if someone’s made a bash-based UEFI shell as a standalone UEFI binary, rather than the standard DOS-imitative shell. Or hell, if it’s possible to make a basic shim atop the standard UEFI ABI to ship glibc and other POSIX stuff and whatever else is needed for basic shell applications to run (for things that don’t expect the Linux kernel to be present and running).
Just download everything worthwhile you find, because YouTube (and the internet at large) is now more amnesiac than some dementia-crippled geriatric. Even a few years ago I’ve found that at least 1/4th of my bookmarks would be dead links in just 2-3 years time.
Additionally, if we’re to use the did:key scheme (or whichever), but end up treating it like a sorta-URL, it might actually be worth having a different scheme ID for referencing objects ‘grouped under’ that DID, because otherwise it’s stretching that scheme outside of it’s original use (being an identifier meant for representing a public key, but now also acting as a sorta-URL too)
Perhaps a property that contains an associative array that serves as a substitution table for any referenced object IDs or it’s children (if I’m not making a grossly bloated proposition)?
Or sorry, I should have read first: you did explain server-independent IDs in FEP-ae97 (I may have overlooked it in the past). I guess I’m cautionary in using DIDs directly as JSON-LD IDs, for the concern of breaking compatibility. I think a separate property could be used instead, despite it adding more cruft (although I don’t know a comparable solution for endpoints in an actor object). Or alternately there having to be alternate representations of objects (DID and legacy), which however would inherently be it’s own separate fediverse entirely.
For server-independent IDs, would that be stored under another property name other than id, or something fully replacing the id or being appended to it and parsed?
If a server is receiving an activity, then it should inherently have some implied discoverability about where the activity is stored, if it wasn’t sent through a relay. I don’t know if there’s some supplemental identifier that could be associated to an instance that’s decoupled from DNS. Maybe a public key-based identifier for a ‘activity/actor storage server’?
For encrypting private data: perhaps start on a simple PGP-ish model, where payload is encrypted directly for the actor’s keypair. People may whine that it doesn’t fill every checkbox of their “demands” for privacy, but it would be trivial to implement, and some later “true E2EE with full forward secrecy” solution can come later as an optional upgrade. Perhaps there’d need to be a new object type (or something borrowed from vocabulary of other JSON-LD-based crypto specs) such as ‘EncryptedActivity’, maybe with an optional type-hint of what the payload activity/object type is (if it’s not anything somehow sensitive).
Ultimately, I do strongly believe FEP-c390 and FEP-ae97 is the inherent future for ActivityPub, or some light variation of it, and I really hope to see the current hack of HTTP Signatures (and especially the current one-key-only per actor representation, for a key that’s just an entirely server-held always-unencrypted private key in a database) to be gradually phased out soon (or at least a shift towards a ‘server key’ for HTTP Signature-based delivery, of something that can be locked down, versus the lie of a private key for each actor, that the actor doesn’t even control, in the current use of HTTP Signatures).
Here’s some predictions I have with soon (<2 months?) releasing a trivially deployable fediverse software, of what’ll happen later down the road after it’s released:
Instance admins will stereotype it as being “nothing more than a tool for abuse”
There’ll be instances that will try to auto-block anything that runs it
I’ll be shit on for “wrecking the fediverse” by letting people be more sovereign and independent from mentally-ill/abusive admins of mega-instances, and for rendering fediblock more useless. More instances might go whitelist-only.
Instance admins will try to dissuade users from emigrating to it, preaching that “but you need to be on my instance, you won’t ‘have wider visibility’ by being on the alternative, besides: you’ll most likely be auto-blocked” or “you’ll be ‘vulnerable’ to all the Nazis out there, you NEED my ‘protection’”.
None of this would be anything by-design nor intentional, it’d just be by mere nature of something that’s easier to deploy on standard hosting, compared to many of the over-architected/arcane predecessors.
Federated platforms are far easier to build, develop for, divvy up moderation responsibilities, and finance rather than “truly decentralized” platforms which I believe pulls in far more risk (how much fun is it running a Tor exit node?), harder to fund (where would Tor/etc be without large universities and charities propping it up?), more content moderation issues (gl;hf dealing with CSAM if you build a ‘completely uncensorable, decentralized’ platform), and so on. At least utility cryptos (e.g Namecoin as mentioned) help solve the finance/commerce issue for some ‘truly decentralized’ ideas.
I don’t think servers are so much the problem. The problem is we have such an adversarial internet backbone and core internet infrastructure now that’s actively trying to prevent routing around censorship intentionally.
Despite my aforementioned concerns with the sustainability of the Tor network, I believe it’s a fairer option (or perhaps I2P, or whatever other overlay networks come about) to be hosting services on Tor/etc instead of clearnet.
Speaking in context of onion services exclusively (and not about interop with clearnet):
Domain seizures on clearnet? So what, nobody can ‘seize’ your onion address on Tor, unless they legitimately have your private key.
ISP shuts you down? So what, move the server elsewhere, come back online, nothing with addressing or any configuration changes at all.
Stuck behind CGNAT and can’t self-host? So what, connect to the Tor network, and you can start hosting services on Tor/etc regardless of what your network topology is. Now everyone can self-host and spread out more.
Afraid of rogue CAs, Cloudflare, and other TLS MitM? So what, the Tor network provides encrypted tunneling that only terminates at the holder of the private key for the respective onion address, far simpler than involving a Certificate Authority or delegated trust system.
I’m sure a response could probably be “well we tried, but nobody really bothers using an onion counterpart fedi server”, and honestly that’s because: a lot of fedi server software legitimately sucks for high-latency networks, especially for things that are heavily client-side rendered. All we need is some simple fedi server implementations that lean more on server-side rendering, and then the experience is far less miserable than waiting a literal minute or so for a Misskey profile to load (for example)
Simple enough. At least Collections/OrderedCollections can have a description (such as the summary property as mentioned in the ActivityStreams vocab spec, in an example). Hopefully I can make use of this for separating out “gallery upload” posts from microblogging posts. Although I guess it probably doesn’t have much utility since I don’t think any implementations let you follow a collection instead of an actor (or to specify what collection(s) you want to subscribe to in a Follow request? ..That would be an interesting extension..), I guess it’s still stuck to needing a ‘virtual’ actor anyway for those sort of ‘substreams’ (like PeerTube does, if I remember correctly).
That’s a bizarre coincidence. I was just noticing streams property in the spec a few hours earlier while reading over it, realizing it’s something I was looking for previously. I assume it’s just up to someone making a semantically proper use of it.
Not sure if it’s intended to be just to be a list of collection URLs, embedded Collection objects, or maybe PropertyType objects?
Oh neat, I think this makes using alternate I2P router implementations more practical as a result as well, given there's so much bundled in the Java implementation that makes it hard to replace.
Well there's LSB and XDG standards just to have basic intercompatibility inside of the Linux world, so that you can jump between GNOME and KDE or whatever, and not have everything fall apart. Standards are fine as long as it's not just to drive monoculture, or to overengineer something just to sell consultancy.
Ultimately I don't care about 'everyone' moving to Linux, I just don't want it where one company is able to get away with sabotaging so much of an industry, and yet have people doing the usual "well, it's what 'the real world' uses" lip service to double-down on their mistake of defending Windows/Adobe/whatever crapware that people trap their livelihoods on. But honestly, the stupider it gets, and the more Microsoft sabotages things, then it's honestly a fate well deserved for its users.
If someone makes a better option than Linux, even if more esoteric, I'd probably be fine with using it for myself (as long as it's some form of free or open source software). I've juggled with BSDs for some use-cases. I'm just tired of proprietary software that's actively fucking over its users, that often gets defended by people unwilling to learn or adapt, or by people just willingly choosing their misery.
DRM and anticheat has been like the lead cause of all problems, even on the targeted platform of Windows itself. There’s plenty of the older games I have from younger years that were a task just to get working on Windows again, such as with ‘Safedisk’ DRM with Sim Theme Park, where you can’t even get past the first loading screen, without several patches or third-party edits just to get it launchable, in Windows.
I agree that Wine/Proton shouldn’t be the end-all solution, meanwhile as Proton came about, it seems like developers just stopped bothering to care about native builds, and too much of the community has grown complacent with Proton. But there’s also the flipside that: ironically older Windows APIs are long-term supported (also just because it’s a clearly distinguished target; a la Win7 or something), and thus it just ends up being ‘easier’ supporting something Windows-only, unless you practically ship a Docker-ish container of userspace libraries your game needs to run on, which Steam on Linux honestly somewhat is: each of the Steam Linux Runtimes (scout, soldier, sniper, etc) are just specific version-froze distro userspace libs, which a developer can target and have assurance is going to be long-term supported.
Compare with plenty of the early Humble Indie Bundle games with DRM-free Linux native builds, where plenty of them are incredibly difficult to natively install now (including having to pull in all the 32-bit libraries, and more), or not at all (because of dependency issues on a no-longer provided version of a library). Thus Linux gaming is primarily down to Valve; there could just be similar community efforts of having an alike container environment (of the same distro targets as the Steam Linux Runtimes) perhaps, to just become the norm for shipping games on Linux, otherwise I don’t know what else there is for options. Flatpak already can do some/all of that, there’s just no specific options decreed as ‘the standard options’, otherwise you’ll end up with probably like 13 different Linux userspace environments installed for like 20 games or something.
So, because you installed VRC on non-Flatpak Steam and had trouble, that inherently nearly every game on Linux is a clockwork to install? Very literally every game I've bought in the past 2-3 years is a "click Install on Steam, and it Just Works" experience. The only hiccup I've had is some issue with Super Animal Royale which just entailed using a newer Proton version. Maybe ask for help, rather than fuming in silence, and then doing the typical tech-boomer blow-up when you reach your breaking point.
Either way, it is helpful that Valve managed to work things out for EAC and BattlEye to make a lot more of the 'popular normie titles' playable on Linux, even plenty of recent titles. Although I don't know if Epic's acquisition of EAC is going gradually to turn the situation to crap again.
Nonetheless, anticheat systems have grown to practically being malware for the over-invasive degree that most of them operate. There's already been vulnerabilities with an anticheat system barely years ago, and yet normies are totally fine with all of this: https://search.brave.com/search?q=genshin+impact+anti+cheat+vulnerability
Just about everything that people used out of jQuery is virtually built into JavaScript or CSS3 at this point, and honestly I’d probably advocate just using plain JavaScript instead of some of the recent overly high-level frameworks
Adding to this: I’m not an iOS/macOS user, but I’ve seen a significant overhaul and uptick of development activity of Monal in the past year, especially since it’s gotten funding for development. https://monal-im.org/https://monal-im.org/post/
It has fairly poor reviews/reputation on the Apple App Store because–those are very old reviews when the project seemed practically abandoned. Reviews/ratings in the past year are more accurate.