Contact introduction requests

[iFergal]

Feature request description/rationale

Lately whenever I connect Alice and Bob's wallets via OOBI URL, I've had Alice automatically send her OOBI to Bob in a /introduce rpy message.

As Bob's parser cannot parse messages from Alice's transferable AID before resolving it's corresponding OOBI, I've taken Sam's suggestion of signing the rpy message using an ephemeral non-transferable AID instead, and it works. The OOBI resolution will result in a new contact if it contains the name query param.

However, I'd like to build something a bit more notification/event driven, so:

1. The wallet can become aware of the new contacts, and react, rather than polling the list of contacts and checking for differences.
2. The creation of the contact could be deferred until the user agrees (so it becomes a request). a. You could also set an auto-accept policy for your agent, e.g. any OOBIs from domain X, and so on.
3. Maybe allow some standardized metadata or profile pics to be sent in the message too.

It would be ideal if there was an acknowledgement that could be sent back too, so that the originating wallet could know if the "connection" has been accepted.

I think then a set of exn messages could be more appropriate than rpy. Would love to hear others' thoughts.

[iFergal]

@SmithSamuelM A couple of weeks ago you mentioned this could be done as a series of rpy messages, or a exn protocol.

The ideal from my team's side is a wallet user having the ability to accept or reject a request to connect, instead of simply becoming aware of a new contact being added.

This to me feels more fitted to an exn protocol; e.g. in KERIA/Signify setup, it would involve the Signify user agreeing. Let me know if you agree, thanks!

---

As a first pass, being able to pass the OOBI, a name, and base64 image in a request would be enough. But it could be extensible for other attributes, or having a way to notify that you want to delete the connection, or something.

What is the best path forward - a PR against kapi?

[SmithSamuelM]

In general if its interactive, then it may be better to use a set of exchange messages. So if you are expecting an ACK that makes it interactive.

[iFergal]

Thanks @SmithSamuelM! Can you advise on the best approach to share a profile image? It would be potentially too big to embed within the exn.

Web hosted: One solution could be to include a URL that contains the SAID, and the client fetches it on demand. KERIA could have a way to host these.

Texter: I also alternatively thought of streaming a Texter after the exn, like we currently do for ESSR. Problems:

• The parser extracts Texters only in the case of ESSR, and I'm not sure if it's intended to do this in other cases.
• The digest of the Texter is the a field of the exn, but I also need to include other fields like the cid, oobi and other metadata the user wants to share.

[SmithSamuelM]

We may want to define a primitive code and/or group code for non-textual data like images.
The group code for a bundle of images and a primite code for each image type. Since images are large in size there would be no advantage to using any of the small (and relatively scarce) prmitive codes for such. We could use the large sizes.

We could also start with a group code for image bundles and then use a texter code embedded in the group for the images until we can devise a schedule for how primitieves should look or at all. But the group code will allow use to attach images and all we would need is a said of the group (make the first field the said of the group calculated the same way the blinded state is calculated. This allows one to anchor the group in any message or in a kel and then the actual data is just an attachment delimited by the group code.

We can also define a manifest as a serialized mapper using the generic map group code embedded in a generic group and then each image is a texter that follows the manifest. The generic group can then be an attachment and embedded in an attachment group etc. This last approach requires v2 of the parser.

[iFergal]

@SmithSamuelM In either approach, how can I give a commitment to the attachment from my exchange message?

In the current parser, if exn.a is a string, a ESSR payload group must be attached to the exn, and exn.a must equal the digest of all texters concatenated.

We could do something similar here but what if I also want to include other key-value attributes in the exchange message, such as cid, oobi, etc?

[SmithSamuelM]

This is a limitation of the version 1 exn message code but not the semantics. So you could instead provided a field map for the a field value where each field's value was the SAID of a different ESSR attachment.

With respect to images. After some more thought including comments from the last dev meetingI think a more refined appraoch would be to define a media typed group code that included a field map of encoded media. Each field in the map consisted of a pair of Texter's the first the label of the map is the CESR encoding of the media type string, the second the value is theTexter encoding of the media itself. The first field in the group before the media list of pairs is a said of the whole group. That way only one said need be referenced in the message to which the group is attached. In the case where its a single messsage the list would only have one element (one pair).

We could be more creative in terms of the encoding but leveraging the existing IAMA standard for media types seems to be a good idea whatever the final structure of the CESR group looks like. We could also do a list of tuples where each tuples has a destriptive lable, the media type, and then the media.

[iFergal]

This is a limitation of the version 1 exn message code but not the semantics. So you could instead provided a field map for the a field value where each field's value was the SAID of a different ESSR attachment.

Thanks, so I presume instead you would calculate the SAID of each attachment, and when calling behavior.verify the handler would ensure there was an attachment for each relevant field for the exn protocol, before calling logEvent to store it?

As right now that SAID verification is done prior to calling behavior.verify. I'm not sure if there are also anything to consider for pipelining.

--

Regarding images, this makes sense to me! If it is a field map, there could be different media objects with the same media type though, so the field key would need something to de-duplicate I think. (list of tuples wouldn't have this issue)

That way only one said need be referenced in the message to which the group is attached.

I'm imaging a scenario where an exn needs to for example reference 2 png images. Without explicit SAIDs of the individual images, it might be ambiguous which is which - but maybe we can rely on the strict ordering of images within the media type group? I think it would be complicated if some images/medias are optional though.

[SmithSamuelM]

Well the most secure approach would be to create an ACDC like partially disclosable structure with a block label, inside the block is SAID field for the block, a UUID for the, block, the image type, and the image. So if you do that then you may just decide to issue an “image” acdc and then include the said of the image acdc in the exn. But there is some advantage to not going full blown ACDC, but having attachments that have similar properties to ACDC sectionsm as described above. In CESR an ACDC blcok is encoded as a field map with labeled fields but the d and u labels are reserved for the block said and uuid. So it can be compacted. A list of tuples that includes a label as the first element of the tuple is semantically equivalent to a field map. If the tuple are not duples (two elements) then a list of vector tuples like this is the well know (tuple space from Linda (Gerlernter)). CESR can effeciently encode tuple spaces. So we just include the SAID of the tuple in each tuple. This is what the new Blinded State for the blindable state TEL does. the blinded state is a quadruple that includes a said and uuid.

[SmithSamuelM]

The Structor class supports tuple spaces. The Blinder class supports blindable tuples. I believe that in general we would want to have privacy protection for a generic solution that is lighterweight than a full blown ACDC. This means a new attachment type that supports blindable media types as a list of blindable tuples. I would nest is one level so that the first tuple is a blindable metadata tuple followed by a list of blindable tuple. We would need to define two new group codes. The group code for the attachment itself and a group code for the blindable media type tuple. Because its only an attachment it only needs to ever be encoded in CESR so it could be a subclass of Structor

The attachement has the following structure in CESR. group code. metadata tuple, list group code one or mode media tuples as list elements.

We could simplify this as just a media type attachment group where by convention the first tuple is always the meta data tuple The attachment group code gives use enough information to frame the group we actually don't need the list group, but it would simplify the logic of parsing the group and it would slso allow us to later exapand the semantics to have nesting inside.

So by forcing a list group we then could also allow a field map group and therefore support arbitrary hierarchical data structures inside the media type group attachment.

[SmithSamuelM]

media type tuple:

(said, uuid , mediatype, media) or (said, uuid , alias, mediatype, media) not sure that we want the alias

meta data tuple:

(said, uuid) or (said, uuid, purpose) not sure that we want the purpose

The purpose and the alias are not strictly necessary. The location of the reference to the metadata said in the EXN or whatever message that media attachment is attached can provide the purpose and allows for more complex semantics with regards the purpose. Likewise for the alias. So my inclination is not to include purpose or alias in the tuples. My experience is these types of descriptive fields add complexity but are never descriptive enough for all use cases so they end up not being used. I suggest we let the enclosing referenced EXN provide that information by virtue of the location of the reference inside the EXN to the attachment as a whole to individual media tuples inside that attachment. Those references are via the SAID so they are cryptographically verifiable references. The structure of the EXN is flexible enough to allow extra fields to amplify the semantics of a given reference.

I only included the suggestions to anticipate the discussion of shouldn't we add additional. fields for descriptive purposes