Some pubsub suggestion

[thomas92911]

Problem:

1. Frequent data publish may lead to flooding and should be limited

2. Data should be time-signed to prevent the publish of large amounts of data pre-prepared (attack)

Suggest:

1. Published data with difficulty signature      signature(sha256(sha256(data + time + nonce))) < 0x0000012345... so massive delivery requires a price

2. Time is defined as the (Time On the Chain), not the real time, is the latest block hash(filecoin, btc,....), so it can't be pre-made.

3. Implement offline message save and route (I am researching this so I don't have to work repeat... :-) )

thomas92911 -- (ARS.China)

[Stebalien]

[admin note: I've moved this to the specs repo and renamed it.]

[Stebalien]

Frequent data publish may lead to flooding and should be limited

Peers can choose which topics they subscribe to and (in go-libp2p-pubsub, at least) they can register topic validators. Such a validator could be used to validate a proof of work.

In general, libp2p's pubsub is a stand-alone protocol that isn't tied to any blockchain. It's really just a low-level transport for building applications (which can validate their own messages).

Implement offline message save and route

libp2p-pubsub is a real-time broadcast system. You may be interested in https://github.com/libp2p/notes/issues/2, a discussion about a potential offline message queue system.

[thomas92911]

Quote my reply at Offline Message Queue #2

Offline messages should really be implemented by the service application. Write dht is not recommended, it is not used in this way.

My initial thoughts：

1. message based on libp2p-pubsub.
2. one application use the same one topic.
3. message-router-service should save message and respond to queries
4. The message sender and receiver first step is exchange the pub-key (say hello) and then use the other's pub-key to encrypt the message.
5. The message receiver reads the to-addr field and determines whether it is parsing or
   forwarding.
6. timeprove use TOC (Time On the Chain), not the real time, is the latest block hash(filecoin, btc,....), so it can't be pre-made.

Message struct example:

key pair:  secp256k1
    pubkey = multibase58btc(multikey-secp256k1(secp256k1 pubkey []byte))
    addr = multibase58btc(multihash-sha256(multikey-secp256k1(secp256k1 pubkey []byte)))

message:
    topic: "IMessageV0S0"
    pubkey: pubkey
    sign: private-key-sign(message)
    message:
        type: 0~...
        to: addr
        route: "-"
        ctime: "123456678"
        timeprove: multiprove("000000000000002cc43169bd.......")
        body: multi-pubkey-encrypt("{...}")
        nonce: "54bacdef51a11416"

message size limit: 2000
message body raw data(before multi-codec):
    size limit: 1024
message type:
    hello
    jcard
    query-jcard
    message
    offline-message
    query-offline-message
    message-receipt