Timeline

This is not an introduction to Nostr, a protocol which describes itself as the simplest open protocol that is able to create a censorship-resistant global "social" network once and for all. There are better resources on the web introducing it:

• Nostr Protocol: main repository of the protocol with many resources of which https://github.com/aljazceru/awesome-nostr is probably the best list with many links to clients, relays and more.
• Nostr, love at first sight: article by Dries Buytaert, creator of Drupal sharing his initial impressions containing a section how it compares to ActivityPub. Dries asked me, on Nostr of course, whether I have more thoughts about that part specifically since I'm maintaining the ActivityPub module for Drupal.

The first moments

Nostr is awesome. It is ridiculously simple. It's hard to come up with better words how exciting the protocol is. The strict separation between client and relay is probably what makes it stand out so hard compared to other 'social' protocols that currently exist.

Whether you're building a client or relay, it takes little time as a developer to either read or post something yourself on the network. It took me less than two hours to contribute a simple Drupal module which allows you to post content to a Nostr relay: https://www.drupal.org/project/nostr_simple_publish. The module itself depends on a PHP library, available via composer so other projects can benefit from it: https://github.com/swentel/nostr-php

If you're on the Nostr network, I'm on there as 'swentel' - find me using my public key: npub1z8n2zt0vzkefhrhpf60face4wwq2nx87sz7wlgcvuk4adddkkycqknzjk5

Nostr vs ActivityPub

First of all: I'm new to the protocol, and I don't necessarily see myself as an expert on ActivityPub either. I just like to experiment with technology, especially if they allow me to expose the content of my site to other networks which I'm doing with both the IndieWeb and ActivityPub modules.

In general, Nostr is very opinionated, which makes it very clear for a developer. In my very short experience, the following 3 things made me smile and shout things like 'Of course!' or 'Finally, someone who gets it!'. Feedback welcome of course if I completely missed something!

1. Authentication and Authorization: Nostr has decided, from the very beginning, how a message should be signed and how it must be verified. This is something that ActivityPub lacks, it only has a recommendation. Until this day, I still haven't fully finished verifying the signatures of incoming activities in the Drupal module because of the subtle differences between the implementation of HTTP Signatures in the many ActivityPub projects that currently exists (e.g. Mastodon vs Pleroma vs Pixelfed and so on). One could argue that these two shouldn't be connected so closely, but I like the strict decision from the beginning.
2. Publishing to a relay: in theory, publishing to one Nostr relay is enough. Relays can then inspect the relays a profile has configured and forward it to others. So, 1 request and you're done. This is something which the fediverse currently lacks, although I've seen people talking about introducing relays as well for the fediverse (can't find any resource now, but this would help reduce server stress a lot!). To give you an example for ActivityPub: I currently have 180 followers which would mean I'd have to send out 180 requests to them when I create a new post and want to notify them when I wrote something new. It's less though (around 83 at the moment) as ActivityPub has a concept called 'shared inboxes' which means I only need to send one request to mastodon.social and any account on there will be notified by the software itself then.
3. Structure of objects: anything you send to the Nostr network is a simple key/value object. Some keys are mandatory when creating the signature and can be validated. Within ActivityPub, the objects can be more complex and have a different structure: a value can simply be a URI, or an array of objects in some cases. It makes it a little more complex as servers need to parse an incoming AP object accounting for different possibilities how a value is formatted. I've lost countless hours a couple of years ago trying to talk with Pixelfed for instance because it made an assumption an a single key always being a string.

I'll add more differences in the future once I played around with it more.

Roadmap of the Drupal module and PHP library

Currently, the idea is to keep the initial module I wrote as simple as possible. While I'm super excited, I still like my free time and don't want to get sucked into building a fully featured client .. yet :)

Patches and feedback welcome on the module or library of course!