Notices by arcanicanis (arcanicanis@were.social)

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

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

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

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.

Cleaner syntax (@method and @path are separate, versus rolling it together as (request-target)), clearly lays out the expectations of which implementation decisions must be made when rolling it into a larger protocol/system (section 1.4), more standardized signature methods (including ed25519), and can be possible to build and make use of well-tested reusable libraries than having to need some niche implementation that only applies to ActivityPub.

In cursory glance, it's just a few syntax changes to 'upgrade' existing implementations. But part of it isn't just RFC9421 itself, but an opportunity to fix the state of HTTP Signatures in ActivityPub within the same effort.

I think it's worth just replacing/upgrading the present state of HTTP Signatures, such as working towards a FEP that instead utilizes RFC9421 (instead of it's earlier incompatible drafts), enabling the ability to have a server-wide key (especially to lock it down to an HSM or other secured storage) rather than this present joke of private keys generated for each user, typically stored unwrapped in a database, that the user can't export for risk of other users on the same instance.

The first step however is defining some mechanism for announcing support for "upgraded HTTP Signatures", as I don't think both could coexist without some discovery/upgrade mechanism: https://socialhub.activitypub.rocks/t/extension-support-discovery/3925

Yes, it won't solve anything with trying to resolve your implementation struggles in the current present, however there needs to be momentum started with fixing this, and garnering support for building a 'better HTTP Signatures', so that people don't have to fight with this absurdity hopefully in the future.

Would it be worth anything for me to spend my day writing a light dissertation between ATProto, ActivityPub, Nostr (very lightly, I still need to dig more), DIDs, etc? (and having to re-read much of the specs again)

If so, expect that it'd be at least as long as (if not more) than: https://arcanican.is/primer/ap-decentralization.php

and just to declare: I've only written a full ActivityPub server implementation, meanwhile I have not written an ATProto server nor anything Nostr yet. I believe I have a fairly complete understanding how it ATProto comes together in it's components, compared to a lot of other people that seem to be commenting on it.

Ooo, I see the Matrix gateway for ejabberd starting to get mainlined in the Community edition, since about a week ago: https://github.com/processone/ejabberd/commit/f44e23b8cc2c3ab7d1c36f702f00a6b5b947c5d0

According to the file headers, it seems to have been started back in late April 2022.

Interesting, there's two different behaviors for bridging account identifiers available:

• matrix_id_as_jid: false: Matrix user ID is treated as a JID (e.g. example@matrix.org); if it can't delivered as an XMPP recipient (if no XMPP service exists as matrix.org, in this example), it then tries via Matrix protocol (as @example:matrix.org)
• matrix_id_as_jid: true: a separate XMPP component is used as the identifier for all bridged Matrix users (e.g. Matrix users appear as example%matrix.org@matrix.xmpp-server.example).

https://github.com/processone/ejabberd/commit/2b7b92edeef6e413570cafacc392720a2baab23b

One thing I assume will be a sizable annoyance: is that E2EE won't be possible across the bridge, unless both sides adopt a mutual E2EE protocol. Thus it might be the first case to see a push for experimental implementation of MLS (from MIMI), or otherwise bring some Olm/Megolm compatibility to XMPP, or OMEMO compatibility to Matrix, as I don't know if those can be 1:1 translated back-and-forth. Or just less-sophisticated things like PGP over instant messaging (like PGP over XMPP as transparently facilitated by plugins).

They're both key ratcheting systems, I just don't know how much Olm/Megolm differs from OMEMO.

But at least it bridges the communication gap to be able to start reaching people on another sizable federated instant messaging network.

I think part of it just comes down to developers of each project having direct communication channels with each other, whether it’s poking each other over email, instant messaging, or direct messages; meanwhile kicking around topics in microblogging format (as something that can get buried to the timeline with everything else), sometimes makes it difficult. I do agree that SocialHub for whatever reason feels difficult to keep up with.

Essentially with FEPs, it feels almost like something that should be treated like trying to get a bill through Congress. “Hey, I’ve got this new proposal, I’ve talked to X and Y project, and they seem onboard, can I count on your support too? Is there any feedback you have on this idea?”

As for Mastodon: fuck it. Everyone else can continue advancing on together, and probably craft things in a “progressive enhancement” manner to augment new things, while Mastodon can act like the “Internet Explorer of the fedi” in it’s own little aimless corner. While the rest of us get to have: custom emote reactions, animation markup, search, post quoting, (now recently) post tipping, and whatever else comes next.

Or with locking down fedi: have some opt-in “strict mode” (that would otherwise ‘break’ federation, if it wasn’t opt-in) that could be advertised in nodeinfo, like in similar nature to HSTS with web browsers regarding strict HTTPS use; or if an actor has keys listed for Object Integrity Proofs, to trust that mechanism only for proving something authentic as originating from that user, and skipping whatever insanity of HTTP Signatures, same-origin, or other mechanisms, etc.