Notices by arcanicanis (arcanicanis@were.social)

I stole a few ideas from did:plc and did:tdw, yes. It's just an experiment insofar, as I'm using it as a stand-in for other methods, as something I can adjust to my needs as I toy with DIDs in a way with reverse-compatibility to standard non-DID ActivityPub.

As it currently stands, there doesn't seem to be a lot of methods that clarify whether DID URLs are permitted or not with the method.

There were a few adjustments I was going to add, such as what other 'authoritative' servers the did:fedi can be discovered from, within the method-specific protocol, maybe.

Either way, I haven't been public about it yet. Just finished a basic key wrapping and serialization format to go along with it, and I'll probably push out a newer version of the generator demo (which presently lacks a polyfill for browsers that don't have native Ed25519 within WebCrypto) in a day or two. I'll probably be more vocal when I have results.

As for the primer, that was probably over a year ago, and the mentioned FEPs, even a year before that (with all those FEPs devised by @silverpill )

I have been reading parts of the DID Resolution spec, yes. There are some inconsistencies I noticed when trying to sorta-implement it, such as the example for "8. DID URL Dereferencing Result" whereas it has didUrlDereferencingMetadata while the current JSON-LD context (which is https://w3id.org/did-resolution/v1 which redirects to a broken URL of https://w3c-ccg.github.io/did-resolution/contexts/did-resolution-v1.json, when I think it's instead meant to go to https://w3c.github.io/did-resolution/contexts/did-resolution-v1.json) defines a property name of dereferencingMetadata instead; or also relative-ref instead of relativeRef in some of the diagrams.

There had been light inferences about using DID URLs for binary content, but it's difficult to see the application of it, when most of it comes to returning a JSON resolution/dereferencing metadata document as an envelope. There's no mention of anything with content negotiation, like if there was a mechanism where: a DID-aware application could ask for the JSON info on resolution, or else, a non-DID-aware application (that doesn't list DID resolution media type in the 'Accept' header) could just be redirected to the dereferenced binary file instead.

There also doesn't seem to be much for options with simply pointing to the location of the resource, rather than embedding the resulting document directly.

I've generally tried just 'making up' some makeshift extensions to fill the gaps in my use-case, and might have some results within a week-ish (I have a resolver implemented with DID URL dereferencing, I just need to make further client-facing changes). There could also be a chance that I might have skipped over something important that might address my complaints, as I'm usually skimming through fragments of all the miscellaneous specs at a time.

I wonder if there's utility in having some sort of "degrees of association" ranking system for dealing with spam accounts. Whereas like the 'Web of Trust' model originally envisioned for PGP, but in this case, not being about asserting legitimacy of real identity, instead just a "not a bot" rating.

Mainly where you'd endorse someone else's account as 'not a bot' on some sort of scale of: recent online acquaintance, long-time online friend, or have met in-person plenty. The risk of course is that such a thing could be abused for datamining, although, some of that could already be heuristically inferred (follower status + frequency of interaction/replies).

This is just a musing of distantly watching the happenings of Nostr in dealing with spam, and seeing if there's ideas that could be implemented in ActivityPub-land first before implementations of key-based portable identities are more widespread.

You don't use link-local addresses in this way. The point of the link-local address is that it can always be directly inferred by it's MAC address and not something you would typically manually assign. There's also annoying specifics with link-local addresses that make them less usable, specifically that they MUST have an interface identifier on them when entering them in any software, like accessing a webpage by link-local address. For example, you HAVE TO do http://[fe80:🔢56ab:cdef%eth0] you can't just do it plain, as the link-local address is meaningless without the device identifier.

The IPv6 link-local fe80::/64 range is like IPv4's 169.254.0.0/16 range, except it doesn't pull numbers randomly out it's as, and again: has the additional oddity of requiring an interface ID at the end. Meanwhile that creates an odd predicament with DNS, even with a HOSTS file.

Nonetheless, what you're looking for instead is the Unique-Local addressing, using the fc00::/7 range, which is more equivalent to IPv4's 10.0.0.0/8 and other private-use IP ranges. Within fc00::/7 it's recommended you only use fd00::/8

If it's two computers directly wired together, you could pretty much just number them as fd00::1/64 and fd00::2/64, or whatever values you want.

There's cleared space around the stage, then a basic perimeter fence around that. Then the risers of attendees behind that (and the chairs in the front). The press were roaming within the cleared space, but probably not desired to be lingering behind the stage (but I don't know, I don't know what their SOP was).

When you start hearing weird shit over radio chatter, then those in a security role start to get tense and probably start actually enforcing things more seriously. I don't think that's a big stretch.

It was supposedly less than a one minute time-window between confirming the anomaly upfront, and the incident happening. A whole cascade of events can happen within ~30 seconds of from hearing something like "There is a confirmed shooter on the roof!" of something, from a department of people that only met probably a few hours/day before (such as being a Secret Service agent hearing something on talkgroup shared with local PD, likely not completely believing it at first, but enough to start getting shifty/paranoid).

Or the Secret Service were shoo'ing them from a space they probably weren't permitted to be in to begin with, and it became push-comes-to-shove in lieu of possible escalating radio chatter about a suspicious person.

I believe it was less than a minute before the incident, is when a law enforcement officer climbed the ladder to the roof the shooter was at, had the rifle turned on them, and supposedly the officer ducked back down and could have radio'ed it in. I believe it was shortly after being discovered that the assailant suddenly rushed into committing their act.

Meanwhile, from the perspective of the agent behind the stage, it was probably getting into a "shit is getting really weird" situation, and probably then started enforcing control of the spaces where even the press shouldn't be lingering, especially if someone were to quickly weasel their way over the back fence, between the blob of press, and pull some unknown stunt. If the space behind the stage is clear, then it's easier to body someone to the ground if they leap the partition. While if it happens from the front, then everyone can see it and react faster.

I'm aware there were reports and indicators possibly up to even 30 minutes in advance of the incident, but meanwhile everyone else enforcing security only have the understanding solely from the location they're posted, and from potentially vague/cryptic details exchanged over radio. Only the sniper team on the top of the barn were those with a far more holistic vantage point of the situation, while the rest of the security were probably posted primarily around the stage and literally 'playing it by ear', with some of the reports seeming unusually surreal to be believed.

When you do security for an event and have to work with people that are terrible at describing something or bad at clearly enunciating their words (or the fact of some digital modes butcher the quality of the audio significantly, especially with the vocoder used in P25), it's another thing that can just add to the mess of inaction.

And to clarify: I'm not saying the security failure was excusable in any way; I'm just trying to give some first-person-like perspective to possibly contextualize it.

Last I remember it only federates blog posts and comments. If the purpose is a blog, then yes, I'm sure that's fully within the use-case. WordPress is fine and pretty mainstream, just don't install a lot of plugins as that increases security risk, as really anyone can publish a plugin (including a lot of web designers that think they know how to code).

If you need any custom theme (or turning an existing design into a WordPress theme), guidance, or auditing, I can provide that.

The point with a self-hosted WordPress install is you have full autonomy over your own website/blog, and nobody can interfere with that.

If you use the SaaS WordPress.com offering, then I'm sure it's not much different of a situation than Substack, other than far more customization.

Edit: additionally, with self-hosted WordPress---it's probably the easiest web application to install on conventional web hosting (LAMP stack) that usually the layperson is able to figure out themself and maintain. And is meant to be widely supported over a broad range of environments or PHP versions, unlike most 'modern' software that's so brittle (and often only deployable via Docker or similar).

I mean, hell, I can just start a managed hosting service (under my pseudonym; I already do such professionally) if there's a market for it on fedi. Just a decade ago it wasn't perceived as that much of a hurdle, as people would pursue through it.

It seems like there's inbound federation issues with chat.wizard.casa. The server-to-server port (tcp/5269) is not open, and there's no SRV record at _xmpp-server._tcp.chat.wizard.casa that indicates another host/post otherwise.

It seems to federating inward properly now. The predicament that made this easy to overlook is: when S2S connections are initiated outward, that same connection also gets used for inbound traffic from that server too (BiDi).

Meanwhile, if a server wants to talk to chat.wizard.casa, it tries connecting to the S2S port, but can't if the port isn't open. It's only when someone on chat.wizard.casa initiates activity outward that it'd "start working" momentarily. But now that's resolved.

Nonetheless, it's probably a usability bug with Dino worth reporting, if it's burying a more critical error (no S2S connectivity) under a lesser-error (can't discover OMEMO keys, because it can't even talk to the server).

The state of the modern web is fairly depressing, in some ways.

~15 years ago anyone could self-publish their own podcast, or even their periodic video series, right from their own website by just tossing up an RSS/Atom feed. And you could have frontends like Miro that would check for new uploads from the feed, and auto-download any recent podcasts/videos you don't have downloaded yet that you could watch offline anytime later, in a convenient video player. Slapping a URL into a feed aggregator wasn't too much to ask of a user. Now instead much of that's centrally-consolidated in a few platforms where you even have to pay a monthly subscription for the "privilege" of 'caching' a video for offline viewing...

Or even just the state of "modern" platforms: I guess the generated DOM of a YouTube webpage is over 2MB of HTML, of over +10,000 elements in the DOM. According to the profiler, it's ~48MiB of in-memory representation for the DOM (+24,000 nodes), and ~48MiB for JavaScript state (640,000+ values). It's much less about optimization now, and more about lofty high-level toolings just to make it cheaper to shuffle around the design periodically. If you want to check for yourself: just open the inspector in the browser developer tools, select the <html> element, right-click, "copy Outer HTML" and paste it to a text editor, and watch it writhe in pain for a little while as it catches up with the clipboard, and save it. Ctrl+F for "</" for a weak estimate of HTML tag count.

Or meanwhile being rendered "obsolete" (as a web developer) by retards with licensed site builder plugins, that still charge like $100+/hour anyway, to build a website on a third-party site builder plugin for WordPress (which already has a block-based editor), that requires at least 512MB of RAM (server-side) to just generate HTML/etc for ONE REQUEST. And where majority of these "professionals" don't even understand how HTTP or DNS works, or how to configure any of that.

I hope there's at least some chance again for an indie web, or people bothering to make crap-less web applications, etc.

Right now on a Prosody server I have, with the daemon process running for 127 days straight, with 5 local users, +8 remote users, 9 connected servers is running at 161MB memory used.

For ejabberd, running for over 3 weeks (after restarting for changes for Matrix bridging), 6 local users, (I don't have the other metrics readily accessible) is running at 115MB memory used.

I do host were.chat, which is registration-by-invite (solely to reduce automated registration and bots), have the domain registered until at least year 2029, have active uptime monitoring and notification, and I tend to keep a deathgrip on keeping things online perpetually, even past their usefulness (such as keeping a forum online for 2 decades now, when it died in activity like a decade ago; and it's shifting into being hosted for preservation/archival sake at this point), so it's exceptionally unlikely that anything I run is going to just disappear.

It may be practical to just set up a server for yourself, as it tends to be lower-maintenance running a Prosody or ejabberd server, which usually has minor updates once every few +6 months or so (and typically nothing critical, like severe security issues). I should probably get around to updating/finishing my guide ( https://arcanican.is/guides/prosody.php ), since pulling in external repo shouldn't be as needed now (in Debian 12, soon Ubuntu 24.04, Fedora 39, etc)

In so far, I don't know of many fedi-adjacent XMPP servers (other than a handful neighbor servers that are predominantly 'furry' tilt, which I assume might not be an adequate fit).

For clients, it's generally 'Conversations' for Android users, Monal IM for iOS users, Gajim for desktop (with Dino as a newer option), and Movim (but I recommend self-hosting it, since it holds your login info on the server, most of the logic is server-side) for a Progresive Web App

I warned you against registering on a mega-server, meanwhile how many interruptions have you had on any of my servers? You're just using the same normie logic as registering on mastodon.social, and then concluding everything else is crap.

I notice several times a day where your chat on conversations.im chokes up, delays messages, and so on; so it's not just them, I'm sure it's the server (probably dealing with varying denial of service). That's why I strongly advocate starting chatrooms on smaller servers, dispersed out.

I guess I successfully created a did:plc and have it published to (sorta) Bluesky's backend did:plc registry: https://plc.directory/did:plc:s2m7kbq2unki7rager5aw6sw/log

Instead of endorsing any sort of a ATProto PDS or anything, I instead have it pointing to my ActivityPub (and other) identifiers in varying forms.

I'm probably the only [non-employee] user (or at least: one of very few) on Bluesky's infrastructure that has full custody and control over their own private keys for their did:plc identity, and yet I don't even have a Bluesky account. Unless I'm just uninformed of something buried somewhere allowing you to export at least one of your rotationKeys (not the signingKey, which is just for signing posts, etc). Because without that, you don't really control your identity at all, only Bluesky exclusively does.

Meanwhile, in this endeavor, I "only" had to:

• Write a DAG-CBOR and CIDv1 encoder
• Write a Multibase and Multikey encoder and decoder
• Write a base58btc encoder/decoder
• Write a base32 encoder
• Write functions to compress and decompress a secp256k1 public key (involves crypto maths, for decompression)
• Write some very adhoc ASN.1 DER encoding/decoding functions (just to encode a raw secp256k1 public key into PEM encoding, to feed to OpenSSL; and then extract the r and s values from the outputted signature from OpenSSL)
• Write a function to generate a did:plc identifier, from the genesis operation
• Write a lot of test code

With how scarcely some topics are documented, and how scattered many tidbits of info is: I swear some of this is almost intentionally a trap to sell consultancy.

If you do rotate the keys to have all users be the same public key, make sure you list both the new and old key in the Update (new key first, which gets stored; old key 2nd/last, which gets discarded), as that's very specifically how the key rotation with Mastodon works (as I also noticed per: https://arcanican.is/excerpts/cve-2024-23832/ )

It's all I routinely bitch about:

https://were.social/notice/AfHlGgRYClScNnQFiy

https://were.social/notice/AfYn3Wcauj4nkflBkO

I assume it was originally under an ambitious idea to allow users to have control over their identity by cryptography, but implemented in such a half-baked way that was conceptually flawed, to the point where users cannot export their keys for risk of the entire server: https://github.com/mastodon/mastodon/discussions/22315#discussioncomment-4423581

It's not just the RFC that just 'magically fixes everything'. I cited that it should be broader effort of working on a FEP, with inclusion of the RFC as a target rather than the earlier draft, including what people want changed of HTTP Signatures, as an initiative that should happen. But also that can't be done yet if we don't have feature/support discovery.

Instead of just shoving a FEP on everyone of "this is how HTTP Signatures needs to be done, everybody needs to do it my way", I'd like to see discussion first (such as on SocialHub) of other potential pitfalls or needs (e.g. what about users on polyglot platforms that don't have a "server" concept, where each user is a sovereign identity, etc, if there's to be a 'server-wide key'?) to be considered.

I don't know if everyone's just afraid of voicing their opinions, if SocialHub is measurably 'dead', if there's just general unseen friction between projects, or if most folks just aren't actionable personality types. If it's legitimately down to someone pushing in a direction, writing up a stack of specifications, and pestering people, I can do that. But I'm sure others likely have more constructive input/insight than what I could do solo.