ActivityPub: the present state, or why saving the 'worse is better' virus is both possible and important
Jan 10, 2019
This is the second article in a series that will be a fairly critical review of ActivityPub from a trust & safety perspective. Stay tuned for more. In our previous episode, I laid out some personal observations about implementing an AP stack from scratch over the past year. When we started this arduous task, there were only three other AP implementations in progress: Mastodon, Kroeg and PubCrawl (the AP transport for Hubzilla), so it has been a pretty significant journey.
ActivityPub: The “Worse Is Better” Approach to Federated Social Networking
Jan 7, 2019
This is the first article in a series that will be a fairly critical review of ActivityPub from a trust & safety perspective. Stay tuned for more. In the modern day, myself and many other developers working on libre software have been exposed to a protocol design philosophy that emphasizes safety and correctness.
The Case For Blind Key Rotation
Dec 30, 2018
ActivityPub uses cryptographic signatures, mainly for the purpose of authenticating messages. This is largely for the purpose of spoofing prevention, but as any observant person would understand, digital signatures carry strong forensic value. Unfortunately, while ActivityPub uses cryptographic signatures, the types of cryptographic signatures to use have been left unspecified. This has lead to various implementations having to choose on their own which signature types to use.
Pleroma, LitePub, ActivityPub and JSON-LD
Nov 12, 2018
A lot of people make assumptions about my position on whether or not JSON-LD is actually good or not. The reality is that my view is more nuanced than that: there are great uses for JSON-LD, but it’s not appropriate in the scenario it is used in ActivityPub. What is JSON-LD anyway?
Do not use or provide DH-AES or DH-BLOWFISH for SASL/IAL authentication
Dec 26, 2014
Atheme 7.2 dropped support for the DH-AES and DH-BLOWFISH mechanisms. This was for very good reason. At the time that DH-BLOWFISH was created, IRC was a very different place… SSL was not ubiquitous, and it was thought that having some lightweight encryption on the authentication exchange might be useful, without opening services to a DoS vector.