fmgp.did.comm.extension
Members list
Type members
Classlikes
Attributes
- Companion
- object
- Supertypes
-
trait Serializabletrait Producttrait Equalsclass Objecttrait Matchableclass AnyShow all
Attributes
- Companion
- object
- Supertypes
-
trait Serializabletrait Producttrait Equalsclass Objecttrait Matchableclass AnyShow all
Attributes
- Companion
- class
- Supertypes
-
trait Producttrait Mirrorclass Objecttrait Matchableclass Any
- Self type
-
L10nInline.type
The received_orders header tells other parties how the sender has experienced the unfolding interaction so far. This allows gaps to be detected, possibly triggering a resend. The value of this header is an array of gap detector objects in the format {"id":
The received_orders header tells other parties how the sender has experienced the unfolding interaction so far. This allows gaps to be detected, possibly triggering a resend. The value of this header is an array of gap detector objects in the format {"id":
"received_orders": [
{"id": "did:ex:bob", "last": 2, "gaps": []},
{"id": "did:ex:alice", "last": 4, "gaps": [2,3]}
]
This lets Alice (or Bob) notice that the auctioneer hasn't seen the messages that Alice numbered 2 and 3. Gaps can then be plugged or ignored, depending on protocol rules.
Attributes
- See also
- Companion
- object
- Supertypes
-
trait Serializabletrait Producttrait Equalsclass Objecttrait Matchableclass AnyShow all
Attributes
- Companion
- class
- Supertypes
-
trait Producttrait Mirrorclass Objecttrait Matchableclass Any
- Self type
Attributes
- Supertypes
-
class Objecttrait Matchableclass Any
- Self type
-
SenderOrder.type
Types
TODO Not currently defined, but reserved for use with a URI that allows calls to a web service that provides translations.
TODO Not currently defined, but reserved for use with a URI that allows calls to a web service that provides translations.
Attributes
TODO Not currently defined, but reserved for use with a URI that allows a localized message lookup table to be downloaded.
TODO Not currently defined, but reserved for use with a URI that allows a localized message lookup table to be downloaded.
Attributes
The sender_order header tells other parties how the sender of a message perceives their own ordering. Its value is a monotonically increasing natural/ordinal number (1..N) that tells how many different messages the sender has sent in the current thread. When Alice and Bob are both bidding in an auction protocol, each of them marks their first bid with sender_order: 1, their second bid with sender_order: 2, and so forth. This allows the auctioneer to detect if Alice's bids arrive in a different order than she intended. It also means that any message can be uniquely identified by its thid, the sender, and the value of that sender's sender_order. Note how this does NOT clarify the sequence of Alice's messages relative to Bob's.
The sender_order header tells other parties how the sender of a message perceives their own ordering. Its value is a monotonically increasing natural/ordinal number (1..N) that tells how many different messages the sender has sent in the current thread. When Alice and Bob are both bidding in an auction protocol, each of them marks their first bid with sender_order: 1, their second bid with sender_order: 2, and so forth. This allows the auctioneer to detect if Alice's bids arrive in a different order than she intended. It also means that any message can be uniquely identified by its thid, the sender, and the value of that sender's sender_order. Note how this does NOT clarify the sequence of Alice's messages relative to Bob's.
Attributes
- See also
The sent_count header enables resend behavior. A resent message contains the same headers (including id and sender_order) and body as a previous transmission. The first time a message is sent, the sent_count for that message is 1, and the header is normally omitted (the value of the header is implicitly 1). The second time the message is sent, the sent_count is 2, and the header is added to indicate that the message might be redundant ("this is the second time I've sent this to you"). The header continues to be incremented with each subsequent resend. Once a recipient has received one copy of a message, they MUST ignore subsequent copies that arrive, such that resends are idempotent.
The sent_count header enables resend behavior. A resent message contains the same headers (including id and sender_order) and body as a previous transmission. The first time a message is sent, the sent_count for that message is 1, and the header is normally omitted (the value of the header is implicitly 1). The second time the message is sent, the sent_count is 2, and the header is added to indicate that the message might be redundant ("this is the second time I've sent this to you"). The header continues to be incremented with each subsequent resend. Once a recipient has received one copy of a message, they MUST ignore subsequent copies that arrive, such that resends are idempotent.
Attributes
- See also