Graduate pubsub from being experimental

[whyrusleeping]

It's probably about time to graduate pubsub out of the realm of just being an experiment.

We should still keep ipns pubsub as an experimental flag, but i think the default floodsub stuff should be enabled.

To do this, let's first have a separate pubsub doc in the docs folder that contains an expanded guide on using pubsub (beyond whats in the experimental features doc). And then just set the flags default value to true.

If the user isnt using any pubsub stuff, there shouldnt be any extra activity going on as a result.

[Stebalien]

So, I have two major issues with the current system:

1. Unauthenticated "from" field in messages.
2. Unauthenticated sequence numbers.

Basically, it's embarrassingly insecure in ways that can't be fixed at the application layer (because users can be DoSed at the protocol layer). The DoS here is that an attacker can easily send messages "from" other peers to hide their messages.

I can see two ways forward.

Content addressed

We can replace sequence numbers/from with a hash of the message (plus maybe timeout?). Users would have to put something new into a message to make it a "new" message.

We could also just take the from, data, and seqno and hash them together to get the "ID". However, the fact that the from isn't authenticated still bugs me. This would be a non-breaking way to fix floodsub but, unfortunately, it'd still break gossipsub.

Sign them

We could authenticate these messages out of the box. Honestly, that's probably what most users would prefer. However, key distribution becomes a bit painful. When receiving a message, the user may have to go back to the sender and ask for the key.

Downsides:

• This would be a completely breaking change.
• Asking for the key could get complicated/slow (for bootstrapping). We could also include the key (or do some kind of optimistic send) but that's also tricky.
• Some systems may not care about authorship. Content addressing + validators allows this kind of thing to be pushed to a higher layer.

Upside:

• Many systems will care about authorship and applications will likely find authenticated messages useful. However, we can always provide a pubsub + auth layer to do this...

---

Personally, I'd prefer to just make pubsub2 (fork the code and protocol) and say "it's experimental".

We could then:

1. Use IPLD for messages.
2. Use CIDs for "message IDs".
3. Do validation at a higher layer.

[whyrusleeping]

We should just implement signing as planned. Also remember EC keys sidesteps the key distribution problem. For RSA keys we could just force them to be included in the message. This would motivate users to upgrade to ed25519 asap

[Stebalien]

Signing as planned works for me (but it will break existing clients).

[Stebalien]

@vyzo want to take a crack at adding signatures?

[vyzo]

Sure! We really want those EC keys though, 2-4kbit overhead per message is quite a bit for RSA keys.

[vyzo]

We also have a deployment/compatibility problem with enforcing signatures.
We can't blanket enforce signatures at one step, it will break existing nodes and be incompatible with them.
Instead, we will have to introduce signatures gradually -- initially sign messages but have optional strict validation, and after signing has been deployed only then make strict validation the default.

[Stebalien]

Sure, but given that this is experimental, I'd say that one release is enough.

[whyrusleeping]

The original idea was the have the authentication scheme be specified in the topic descriptor. So if you listen on a topic that has signatures, then you better sign your messages or they will get discarded.

[Stebalien]

The original idea was the have the authentication scheme be specified in the topic descriptor. So if you listen on a topic that has signatures, then you better sign your messages or they will get discarded.

Given that we're using from/seqno for deduplication, I think we really have to sign all messages (although we don't necessarily need to encrypt them).

I agree that the topic descriptor should specify the authentication scheme. However, I think that relates more to who can publish, not whether or not messages should be signed.

[vyzo]

Message signing implementation: libp2p/go-libp2p-pubsub#97

[rklaehn]

So any update on when this feature (I guess gossipsub now) will be made non-experimental? Note that non-experimental does not mean that it is bug-free, but just that it should usually work and will not change in a fundamental way.

For people like us ( actyx.io ) that use this in production it is really scary to depend on several experimental features ( private swarms + pubsub )....

[whyrusleeping]

Ive chatted with @Stebalien and @daviddias about this recently, and I think there's no reason not to graduate this API to being official. Thoughts @Stebalien?

…

On Mon, Jan 28, 2019, 5:42 AM Rüdiger Klaehn ***@***.***> wrote: So any update on when this feature (I guess gossipsub now) will be made non-experimental? Note that non-experimental does not mean that it is bug-free, but just that it should usually work and will not change in a fundamental way. For people like us ( actyx.io ) that use this in production it is really scary to depend on several experimental features ( private swarms + pubsub ).... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5383 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABL4HO6pPzwzSnByi17nbQiQ1Q3_vXrfks5vHv4_gaJpZM4V-gqE> .

[daviddias]

@whyrusleeping here is a proposal. Let's get the PubSub API written as a spec and officially change the stamp from draft to reliable -- https://github.com/ipfs/specs#work-in-progress

[Stebalien]

I have no more protocol level concerns. My only remaining concern is implementation related: we still have some races concerning disconnects/reconnects (libp2p/go-libp2p-pubsub#133). However, there's no reason to block on that as we can fix it without any protocol breaking changes.

@vyzo?

[vyzo]

no objections here...

[lidel]

IIUC discussion moved to #6621