Notices by arcanicanis (arcanicanis@were.social), page 4

There’s so much that could be solved if people just carried the same pattern of being dissatisfied with something in very specific ways, and actually getting up and making their own thing for once. We have such an abundance and ease of developer tools, yet so many are so anemic to making anything.

additionally, I do have a whole sorta-‘Wireshark-style’ interface already for diagnosing federation activity, and much of the error responses actually tell you what’s wrong with your request (“failed to fetch actor”, “request missing signature”, etc), so some of it may even serve as a developer tool for testing a new fedi application, rather than having to set up some HTTPS MitM utility just to debug requests. Screenshot from a while ago, as attached.

what are you working on?

Essentially creating what I wanted a GNU social rewrite to actually be:

• Written in very simple, flat code (as PHP projects used to be) that can be easily modded (inline, or as plugins) and not just habitually pull in some framework or design patterns that aren’t even needed.
• Trivial to install, just by extracting and following a web installer. Nothing to deal with of running any build scripts or package management tools.
• Something that doesn’t require JavaScript for all functionality, while JavaScript is provided for progressive enhancement. Something that doesn’t pull in sizable JS libraries when things can be cleanly and performantly done in plain JS instead, most of the time.
• Long-term platform support, rather than something cranking up the minimum version requirements for no reason. In other words: software you could actually run on LTS platforms equivalent to CentOS, and not break from an update (like from bumping the PHP minimum requirement for the lulz).
• Able to run in constrained hosting environments, such as shared hosting providers
• Something fault-tolerant that can continue hosting public content, even if the application shits itself.
• Something that can just let the web server directly serve public content, rather than using the application like a second webserver to make all request routing decisions.
• Something that gives me exposure of it’s internal workings in an actual admin panel, that I can even keep an eye on federation activity, rather than having to pick apart a database to inspect deliverability, retries, etc.
• Something that allows me to prototype and tinker, to craft custom requests/activities, to experiment with new ideas, of essentially a developer console available for those with certain admin privileges.

Surprisingly I still don’t have an official name yet. Effectively it’s meant to be another social media platform, but where I’d like to “roll Pleroma, PeerTube, and maybe an art system, into one application”, or that could be extended into fulfilling that via plugins. It sounds far-reaching, but much of that’s just purely cosmetic details of layout, and I find it a bit pointless that a whole separate software is “needed” just to provide a “YouTube-like layout” for video/art uploads (instead of ‘microblogging feed layout’).

It’s easy to implement, it just may be hard to model and structure it in a clean orderly way, if you don’t know where some ideas will lead. I’ve refactored my current project a few times in the past year, and now I finally think I have my magnum opus, while it was fairly ugly before.

I could have actually had something years ago, back when the standard was reaching ratification, but I fell into the trap of trying to make JSON-LD the first priority. Pretty much any of the projects that just parse ActivityPub as plain JSON were the ones to actually go anywhere.

That’s pretty much all it takes. I find it bizarre that so many will cling to certain poorly-designed software rather than just write their own, especially for certain focused niches.

Opt into the Steam Client Beta (in order to be able to actually run SteamVR v2); additionally, opt into the ‘beta’ channel for SteamVR. Be conservative with installing SteamVR updates sometimes, because it feels like Valve (or whatever contractor they hire) likes to break things randomly. Nonetheless, the beta channel has become fairly stable and reliable, weirdly more than the non-beta channel. There’s actually a lot more working now than there was a year ago (such as ‘desktop view’ and such in the SteamVR HUD, which would normally be finnicky, or not run at all).

Source: I use a Valve Index exclusively only on Linux on a near-weekly basis.

For the past year, ‘Half Life: Alyx’ has been unlaunchable for me, and ‘SteamVR Home’ doesn’t launch. I haven’t seen any maintenance on Alyx whatsoever for like probably 2 years.

Meanwhile I’m able to launch Resonite (through Proton) just fine: https://store.steampowered.com/app/2519830/Resonite/ Serious Sam VR also works.

Do you have a fairly recent Proton version set as default, in the main Steam settings (Steam > Settings; Compatibility)?

Are you on the SteamVR 2.x branch, or 1.x yet?

I’ve no idea what the ‘correct’ one was; because the way it explains which ones were ‘failed’ are just vague categorical descriptions, like you see in @Pawlicker ‘s photo above. Edit: In fact, I don’t think I even given a summary of which ones were failed, in my results. Just the score, the score requirement, and PASS or FAIL.

It may as well just be called “Windows+”. But nonetheless, in Security+ there is a handful of Linux CLI questions at least; though I just generally hate the nature of CompTIA questions in general. e.g. there was one question was like:

Which of the following is a valid iptables command?

• iptables-A INPUT -p tcp --dport 22 -j ACCEPT
• iptables --add INPUT -p tcp --dport 22 -j ACCEPT

Oh, but just “choose the answer that’s ‘more right’”!

I’d point more to it relying on MDB2 for all the database interactions, whereas MDB2 doesn’t work in recent versions of PHP which broke some things of reverse-compatibility (supposedly in the sake of better performance?), and that library hasn’t been updated for beyond a decade: https://pear.php.net/package/MDB2

It’s that it may entail reworking anything DB-related to move off of MDB2, which could be the whole project, or else fixing MDB2 to run in ‘modern’ PHP. I assume everyone would rather just write something entirely new, but pretty much any of the efforts miss the point, such as not doing: easy moddability via plugins, being able to run on constrained hosting environments, being able to just extract an archive and use a web installer versus expecting everyone to be a Linux neckbeard to use build tools, etc.

Well, it depends on what you’re referring to.

There’s the promise that Bluesky will federate eventually, and there hasn’t been much indication of anything beyond whitelist-only federation that I’ve come across yet. Also they were boasting about having an ‘open protocol’ but yet there were significant disparities between their specification and what they had in production (even in a variety of light variations or typos of attribute names, etc).

Are you sure you’re not mistaking the DNS aliases as federation? Because that’s like no different than someone thinking they “run a server” because they created a Discord guild (per the Discord’s misleading marketing).

There’s also plenty of excuses and possibly ‘misinfo’ in their side as well regarding ActivityPub, of just making an excuse for making a whole separate protocol, where they initially hold federation exclusively to themselves for a period, so that they’ll always have a stronghold grasp on ‘their’ ATProto network (by user count and site age), and where development and direction on that network will be entirely dependent on whether the flagship instance bothers to ever support any third-party extensions to the protocol. It’s just as “decentralized” as the LBRY network of Odysee.

Also, when you devise a protocol, you don’t just have one group make it, then it’s on everyone else to adopt it; you have two or more separate groups make their own implementations of it, to test if the standard is even sane, rather than just figure out and test interoperability later. It’s generally a prerequisite to most standards bodies for a reason.

In regards of their remarks on ActivityPub: it’s operationally a meritocratic living standard; it’s not about what’s solely enshrined by the W3C nor how only one software (Mastodon) implements it, as their FAQ seems to imply their outlook on it. Also, majority of implementations just end up implementing it as plain JSON rather than full true JSON-LD support. There’s also no standard nor FEP that mandates double-at representation, that’s primarily a Mastodonism (more on the aspect of mandatory WebFinger resolution).

Also the remark that identity and data portability as not being retrofittable to ActivityPub, yet there’s discussions and efforts with proposed FEPs to establish exactly that. I reasonably believe we’ll have ID/data portability in some ActivityPub implementations before the day that Bluesky is full open federation, built on much more matured codebases. Much of the complaints of ActivityPub are being resolved as a larger meritocratic group effort (by proving it with code and implementation), but users evidently want to throw out entirely everything, just to gravitate to the newest shiny Venture Capital funded start-up, learning absolutely nothing from ditching out from Twitter.

List the technical flaws then (and I don’t mean that in a sarcastic rhetorical tone).

That reads a lot like the “Crypto/Web3 is going great” channels that are always circlejerking on sometimes incorrect information, just to have something to mock and reaffirm biases.

Software can’t fix people, software can’t fix emotionally unstable admins, trying to consolidate everyone on one service (not implying that Bluesky is ‘forever a silo’ or anything) isn’t a solution either. The social problems that inhibit federated protocols and networks aren’t the problem, it’s the decay of moral standards and decorum that is the greater issue, because without that addressed you can’t have reliable federated networks. Even the internet itself is increasingly fracturing and becoming unreliable over social/political antics in recent years, like people pulling stunts on the continental internet backbone level, because they don’t like people being able to access content on a particular website. If you have protocol-level suggestions, I’d be glad to hear of ideas.

You can’t have a mega-platform while also doing simultaneously doing gatekeeping to keep only “our guys” on it, just as especially of people ditching out from fedi just to escape “the Nazis”, when they’re only going to keep platform hopping on the next trigger they find.

There’s been a handful of dissertations I’ve seen from others attesting to being some authority figure on the subject (regarding ActivityPub), that I strongly disagree with on the technical remarks of, that I want to get around to writing a response to at some point on a personal website.

As for things that are being actively worked on and developed:

Seeing all the responses to a post, versus the present ‘split-brain’ post discoverability: there’s an architectural reason that even if you have the server of the parent post track all the responses, that you couldn’t just have a remote server pull all the responses. Because even if the parent server lists all the known responses to a post (local and remote), that there’s no proof of authenticity for remote posts, thus every single remote reply would have to be re-queried. Think of hellthreads, and a sudden flood of +500 queries from just one server querying a thread, that’s obviously a bad idea.

Thus, the solution to that is establishing a framework of ActivityPub object signing, of portable inline object signatures. Whereas: as long as the querying server has a cached copy of the actors in the thread, it can verify the authenticity of their posts mentioned in a ‘replies’ list on a discussion on another server, without having to directly query every single reply post from it’s respective originating server, as long as the whole object is in the ‘replies’ collection (not just the object IDs). There’s already extensions being experimented upon for object signing: https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md

Then with object signing, as well as further extensions to cryptographically sign actors, and authenticating a key to represent an identity (e.g. FEP-c390), you can start to build an framework for portable objects and identities, such as recent proposed experiments of: https://codeberg.org/silverpill/feps/src/branch/main/ef61/fep-ef61.md

It’s a patient process of formulating ideas and solutions to make something that works, rather than just dumping it all of it as a lost cause, and swapping over to some replacement that most people don’t even know the deep implementation technicals of yet (opposite of the notion “better the devil you know, than the devil you don’t”, or perhaps instead directly “the grass is always greener on the other side”). Some of it takes work and effort, but it’s absurd to just drop everything once the shortcomings are apparent: if there are shortcomings, you FIX them, you don’t just shrug it off and shuffle over to the next marketed gimmick.

There’s also a list of plenty of other fantasy consoles, some that are FOSS and web-friendly: https://github.com/paladin-t/fantasy

Ironically, I wouldn’t be surprised if some consistent subset of Flash or Shockwave would actually be a fair option, as most of the security complaints about Flash were mainly for it being too privileged and having unsafe methods of browser integration (and ‘trusting’ Adobe to solely steward all this). Whereas running Flash stuff in Ruffle, within a webpage (not with any extended privileges in a browser plugin or desktop app) really wouldn’t be too controversial.

There are actually still some funded competitions on Newgrounds of still producing Flash content yet, even in like 2022 or so.

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).

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).