search

wirelineio / wireline-core

GNU Affero General Public License v3.0
1 stars 1 forks source link

Interim Bot Party Admission Mechanism #94

Closed dboreham closed 5 years ago

dboreham commented 5 years ago

From Slack:

If we assume that every running bot instance is owned by some human. And every running bot instance should optionally be discoverable and reachable by anyone running launchpad. (optionally, in that, if I'm just debugging a bot for my own private purposes, then it doesn't need to be advertised) And we further assume that we will continue to use the registry as the advertisement system for bots. David 8:10 AM We could make the following small adjustments to our model:

  1. A bot advertised in the registry represents a single running instance of a bot, owned by someone.
  2. To avoid polluting namespace with many similarly named bots, we use the namespace mechanism (or something similar if we have time) to maintain clean namespace. Each human gets one (or more) namespaces they (purely by convention at present) advertise their bots in.
  3. Bots can participate in multiple parties (I know...) but only in support of whatever their owner is doing. E.g. I'm testing launchpad and I reset storage, I get a new party but I can still use the bot I have running on my laptop with it. I don't need to spin up a new bot or reset my bot just because I reset launchpad storage. This doesn't mean "bot for the whole world's parties".
  4. Launchpad party member bot query UI allows dynamic namespace selection -- defaults to default namespace, which would show no bots. User can change namespace easily to e.g. "chrisbots" and see whatever bots were advertised under that namespace. David 8:29 AM
  5. Finally, we implement some "lite" version of the new party admission mechanism Ashwin has been working on, for bots. I think this would in fact be not too different from the current bot party join protocol. The new party invite/admit mechanism works like this: We advertise a party key as a topic in swarm. The deal offered is: if you connect to me asking for a feed with that key, I will ask you to prove you have the right to be in the party. If you give that proof, I will add you and I'll give you the party content I have. Proof to be in the party is conveyed in an off party message we call an invite. For bots I think we can tweak that mechanism slightly: a. Bots have a unique key. They advertise this key in the registry, and they also advertise it as a topic in swarm (this is what happens now, conveniently) b. Peers (launchpad) can decide to admit a bot to a party they're already in. c. They do this by making a connection to a node for the bot key, via swam (also what happens now) d. Upon receiving the incoming connection, the bot expects to receive a party key which the peer (launchpad) supplies, via dat protocol extension messages. e. The bot now has the same information as is contained in a regular launchpad invite and so can now join the party, either within the same open connection, or by dropping the connection and making a new one to join. I don't know the details, but I suspect d. and e. are very close to what happens now too. All of the above assumes that all the nodes are using the same signaling server, but that's a restriction we also have at present, until we have a global/federated discovery system. a-e is like the new party mechanism, but just skips all the checks. So bots will talk to any launchpad and launchpads will talk to any bot. Let me know thoughts on this, any flaws in the logic. David 8:48 AM One problem I can see is that it isn't using the key in the spirit of Dat: that a key is associated with some data that you can potentially get from a number of different places Instead, it's using the key as a kind of "unique endpoint locator" for a single bot process. This feels a bit odd, but it's also what we've been doing already. And it has the benefit of actually working, through NAT and with roving devices, which an IP address or http URL wouldn't, without some fancy proxy thing or dynDNS that knew how to deal with NAT and roving. RB 11:26 AM this all sounds good can you copy all of this into an issue body re #5, i think this depends on whether we're going to commit to MF2 integration @Max @Martin re "spirit of dat", yes, that's been an ongoing discussion -- what does the discovery key mean: spectrum: FILE > DIRECTORY > PARTY > GROUP > EVERYONE (in order of decreasing specificity and increasing reach)
dboreham commented 5 years ago

@richburdon @tinchoz49 @ashwinphatak