Push based messaging.

[jayrbolton]

So metadat is setup for

• public pull-based messaging. User A can broadcast public data into their public metadat and any followers can pull that data
• private pull-based messaging with one-to-one and one-to-group. User A can put data in a "relationship metadat" for user B, and user B can read those updates

However, it would be nice to add push-based messaging. This would allow user A to message user B without user B knowing user A. The push messages could be handled by the receiver according to a hardcoded set of message types built into metadat (eg "initiate-contact", "send-dat", etc). Maybe this can be done with hypercore

[lukeburns]

The receiving peer needs to learn about the sending peer's key somehow (in order to get the relationship dat). You could maybe have every peer listening on a discovery-swarm channel for establishing relationship dats with initiating peers (e.g. something like https://www.npmjs.com/package/hyperexchange), but this still only works if each peer is always running this server. a way around this might be by forwarding messages through other peers.

[aschrijver]

This is very much related to the message layer proposal + design I'm working on:

Messaging proposal

• part 2: Dat: A message-based system on top of raw streams
  • part 2a: Design of message-based abstraction layer on top of hypercore
  • part 2b: Investigating message abstraction layer implementation options

[jayrbolton]

In dat-pki, I'm going to move forward with doing just pull based messaging where both users have to be aware of each other, after relationship and/or group dats have been established among everyone.

For now, I'd like to implement everything useful we can think of using only the current dat-node api. Maybe another way to do "push messaging" would be to allow people to optionally enter email addresses and use that in some way. @lukeburns do you have hyperexchange on github so i can look at it in more detail?

[lukeburns]

@jayrbolton just added it here: https://github.com/lukeburns/hyperexchange. all it does is set feed.id = feed.key which is then exposed to peers via socket.remoteId. It doesn't actually verify that you've received a key from the person with that key. if you did this with dat-pki, you could verify by checking to see if the metadat of the key you've been handed has initiated a handshake.

a similar approach to this might be to pass around initialized handshakes that you've learned about from other peers in userData w/ hypercore-protocol so that you don't need to make a direct connection to the peer you want to handshake with -- they just need to connect with someone you've told about the initialized handshake.

[jayrbolton]

What do you think about just including a little TCP daemon that can handle push messaging for users as part of this library? All messages sent over tcp can be encrypted to them using their pubkey. This could be used for receiving encrypted messages (eg dat addresses) from people you don't know, without initial handshakes. Every device for every user would run a tiny TCP server.

[lukeburns]

Are you imagining just sending user messages over the TCP server, or using that TCP server to establish a relationship dat? If the former, we lose verifiable message history and all the features of dat, which I think would be desirable to preserve. If the latter, it would totally work, but it might also be accomplished during the hypercore handshake without the additional overhead.

[jayrbolton]

Haha, I forgot about that comment! I just meant the latter, and maybe using discovery-swarm instead with the swarm id being the user's "profile dat", other users would then send their own public profile dat addresses over this swarm. I'm not sure that's the best way though -- open to suggestions
Sorry I haven't worked on this for months... I keep getting pulled into other projects. I've been wanting to get back into it lately though. See this writeup I was playing with recently: https://github.com/jayrbolton/dat-wot/wiki/dat-wot-plans