update all references from master to main

0000-template-protocol.md

@@ -13,7 +13,7 @@
 
 One paragraph explanation of the feature.
 
-> If the RFC you are proposing is **NOT** a protocol, please use [this template](https://github.com/hyperledger/aries-rfcs/tree/master/0000-template.md) as a starting point.
+> If the RFC you are proposing is **NOT** a protocol, please use [this template](https://github.com/hyperledger/aries-rfcs/tree/main/0000-template.md) as a starting point.
 
 > When completing this template and before submitting as a PR, please remove the template text in sections (other than **Implementations**). The implementations section should remain as is.
 
@@ -33,9 +33,9 @@ Protocol names are often either lower_snake_case or kebob-case. The non-version
 
 URI: https://didcomm.org/lets_do_lunch/<version>/<messageType>
 
-Message types and protocols are identified with special URIs that match certain conventions. See [Message Type and Protocol Identifier URIs](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md#message-type-and-protocol-identifier-uris) for more details.
+Message types and protocols are identified with special URIs that match certain conventions. See [Message Type and Protocol Identifier URIs](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/README.md#message-type-and-protocol-identifier-uris) for more details.
 
-The version of a protocol is declared carefully. See [Semver Rules for Protocols](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md#semver-rules-for-protocols) for details.
+The version of a protocol is declared carefully. See [Semver Rules for Protocols](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/README.md#semver-rules-for-protocols) for details.
 
 ### Key Concepts
 
@@ -50,7 +50,7 @@ variants.
 
 ### Roles
 
-> See [this note](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols/roles-participants-etc.md) for definitions of the terms
+> See [this note](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0003-protocols/roles-participants-etc.md) for definitions of the terms
 "role", "participant", and "party".
 
 Provides a formal name to each role in the protocol, says who and how many can
@@ -61,7 +61,7 @@ credential must be known to the issuer").
 
 The formal names for each role are important because they are used when [agents
 discover one another's
-capabilities](https://github.com/hyperledger/aries-rfcs/tree/master/features/0031-discover-features);
+capabilities](https://github.com/hyperledger/aries-rfcs/tree/main/features/0031-discover-features);
 an agent doesn't just claim that it supports a protocol; it makes a claim about
 which *roles* in the protocol it supports. An agent that supports credential
 issuance and an agent that supports credential holding may have very different
@@ -76,7 +76,7 @@ errors, and what should happen to state as a result. A formal representation of
 this information is provided in a _state machine matrix_. It lists events as
 columns, and states as rows; a cell answers the question, "If I am in state X
 (=row), and event Y (=column) occurs, what happens to my state?" The [Tic Tac
-Toe example](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/tictactoe/README.md#states) is typical.
+Toe example](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/tictactoe/README.md#states) is typical.
 
 [Choreography Diagrams](
 https://www.visual-paradigm.com/guide/bpmn/bpmn-orchestration-vs-choreography-vs-collaboration/#bpmn-choreography)
@@ -92,8 +92,8 @@ the matrix form is used in many early RFCs. We leave it up to
 the community to settle on whether it wants to strongly recommend specific
 diagram types.
 
-The formal names for each state are important, as they are used in [`ack`s](https://github.com/hyperledger/aries-rfcs/tree/master/features/0015-acks)
-and [`problem-report`s](https://github.com/hyperledger/aries-rfcs/tree/master/features/0035-report-problem)).
+The formal names for each state are important, as they are used in [`ack`s](https://github.com/hyperledger/aries-rfcs/tree/main/features/0015-acks)
+and [`problem-report`s](https://github.com/hyperledger/aries-rfcs/tree/main/features/0035-report-problem)).
 For example, a `problem-report` message declares which state the sender
 arrived at because of the problem. This helps other participants
 to react to errors with confidence. Formal state names are also used in the
@@ -103,22 +103,22 @@ By convention, state names use lower-kebab-case. They are compared
 case-sensitively.
 
 State management in protocols is a deep topic. For more information, please
-see [State Details and State Machines](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/state-details.md).
+see [State Details and State Machines](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/state-details.md).
 
 ### Messages
 
 This section describes each message in the protocol. It should also note the names and
 versions of messages from other message families that are adopted by the
-protocol (e.g., an [`ack`](https://github.com/hyperledger/aries-rfcs/tree/master/features/0015-acks)
-or a [`problem-report`](https://github.com/hyperledger/aries-rfcs/tree/master/features/0035-report-problem)).
+protocol (e.g., an [`ack`](https://github.com/hyperledger/aries-rfcs/tree/main/features/0015-acks)
+or a [`problem-report`](https://github.com/hyperledger/aries-rfcs/tree/main/features/0035-report-problem)).
 Typically this section is written as a narrative, showing each message
 type in the context of an end-to-end sample interaction. All possible
 fields may not appear; an exhaustive catalog is saved for the "Reference"
 section.
 
 Sample messages that are presented in the narrative should also be checked
 in next to the markdown of the RFC, in [DIDComm Plaintext format](
-https://github.com/hyperledger/aries-rfcs/tree/master/features/0044-didcomm-file-and-mime-types#didcomm-messages-dm).
+https://github.com/hyperledger/aries-rfcs/tree/main/features/0044-didcomm-file-and-mime-types#didcomm-messages-dm).
 
 The _message_ element of a message type URI are typically lower_camel_case or lower-kebab-case, matching
 the style of the protocol. JSON items in messages are lower_camel_case and inconsistency in the
@@ -183,7 +183,7 @@ needs to be known about all message fields, this is where the data type,
 validation rules, and semantics of each field in each message type are
 details. Enumerating possible values, or providing ABNF or regexes is
 encouraged. Following conventions such as [those for date-
-and time-related fields](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0074-didcomm-best-practices#date-time-conventions)
+and time-related fields](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0074-didcomm-best-practices#date-time-conventions)
 can save a lot of time here.
 
 Each message type should be associated with one or more roles in the 
@@ -211,15 +211,15 @@ If communication in the protocol involves humans, then localization of
 message content may be relevant. Default settings for localization of
 all messages in the protocol can be specified in an `l10n.json` file
 described here and checked in with the RFC. See ["Decorators at Message
-Type Scope"](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0011-decorators#decorator-scope)
-in the [Localization RFC](https://github.com/hyperledger/aries-rfcs/tree/master/features/0043-l10n).
+Type Scope"](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0011-decorators#decorator-scope)
+in the [Localization RFC](https://github.com/hyperledger/aries-rfcs/tree/main/features/0043-l10n).
 
 ### Codes Catalog
 
 If the protocol has a formally defined catalog of codes (e.g., for errors
 or for statuses), define them in this section. See ["Message Codes and
-Catalogs"](https://github.com/hyperledger/aries-rfcs/blob/master/features/0043-l10n/README.md#message-codes-and-catalogs)
-in the [Localization RFC](https://github.com/hyperledger/aries-rfcs/blob/master/features/0043-l10n).
+Catalogs"](https://github.com/hyperledger/aries-rfcs/blob/main/features/0043-l10n/README.md#message-codes-and-catalogs)
+in the [Localization RFC](https://github.com/hyperledger/aries-rfcs/blob/main/features/0043-l10n).
 
 ## Drawbacks
 

0000-template.md

@@ -11,7 +11,7 @@
 
 One paragraph explanation of the feature.
 
-> NOTE: If you are creating a **protocol** RFC, please use [this template](https://github.com/hyperledger/aries-rfcs/blob/master/0000-template-protocol.md) instead.
+> NOTE: If you are creating a **protocol** RFC, please use [this template](https://github.com/hyperledger/aries-rfcs/blob/main/0000-template-protocol.md) instead.
 
 ## Motivation
 

concepts/0003-protocols/tictactoe/README.md

@@ -29,7 +29,7 @@ capture 3 cells of the grid in a straight line.
 ### Name and Version
 
 This defines the `tictactoe` protocol, version 1.x, as identified by the
-following [PIURI](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols#message-type-and-protocol-identifier-uris):
+following [PIURI](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0003-protocols#message-type-and-protocol-identifier-uris):
 
     did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0
 

concepts/0004-agents/README.md

@@ -4,7 +4,7 @@
 - Status: [ACCEPTED](/README.md#accepted)
 - Since: 2019-01-15
 - Status Note: On a standards track and beginning to influence many mental models, but not yet [ADOPTED](/README.md#rfc-lifecycle). 
-- Supersedes: [Indy HIPE 0002](https://github.com/hyperledger/indy-hipe/tree/master/text/0002-agents)
+- Supersedes: [Indy HIPE 0002](https://github.com/hyperledger/indy-hipe/tree/main/text/0002-agents)
 - Start Date: 2017-11-01 (approx, backdated)
 - Tags: [concept](/tags.md#concept)
 
@@ -169,7 +169,7 @@ Here are some thought questions to clarify intent:
 We said it's hard to provide a recipe for an agent without specifics.
 However, the majority of agents _do_ have two things in common:
 they listen to and process A2A messages, and they use a [wallet](
-https://github.com/hyperledger/indy-hipe/blob/master/text/0013-wallets/README.md)
+https://github.com/hyperledger/indy-hipe/blob/main/text/0013-wallets/README.md)
 to manage keys, credentials, and other sensitive material. Unless you have
 uses cases that involve IoT, cron jobs, or web hooks, your agent is
 likely to fit this mold.
@@ -236,7 +236,7 @@ in the DID Doc of the recipient, and finding an intersection
 between transports they use, and transports the sender can
 speak. Line 3 requires the keys of the sender, which would
 normally be held in a [wallet](
-https://github.com/hyperledger/indy-hipe/blob/master/text/0013-wallets/README.md).
+https://github.com/hyperledger/indy-hipe/blob/main/text/0013-wallets/README.md).
 
 If you are building this sort of code using Aries technology, you
 will certainly want to use [Aries Agent SDK](
@@ -253,7 +253,7 @@ or in its Getting Started Guide.
 
 * Hang out and ask questions on `#aries` on [chat.hyperledger.org](https://chat.hyperledger.org).
 * Use the mailing list: [[email protected]](mailto:[email protected])
-* Follow the Aries Cloud Agent - Python [Getting Started Guide (for developers)](https://github.com/hyperledger/aries-cloudagent-python/tree/master/docs/GettingStartedAriesDev)
+* Follow the Aries Cloud Agent - Python [Getting Started Guide (for developers)](https://github.com/hyperledger/aries-cloudagent-python/tree/main/docs/GettingStartedAriesDev)
 * Study the [Aries Protocol Test Suite](https://github.com/hyperledger/aries-protocol-test-suite) |
 * Study the sample mobile agent at [github.com/sovrin-foundation/connector-app](https://github.com/sovrin-foundation/connector-app).
 * Browse other [RFCs](../../index.md).
@@ -365,7 +365,7 @@ that gap.
 ###### Identity Wallets
 
 "Identity wallet" is a term that's [carefully defined](
-https://github.com/hyperledger/indy-hipe/blob/master/text/0013-wallets/README.md#what-is-an-identity-wallet)
+https://github.com/hyperledger/indy-hipe/blob/main/text/0013-wallets/README.md#what-is-an-identity-wallet)
 in our ecosystem, and in strict, technical usage it maps to a
 concept much closer to "database" than "agent". This is because
 it is an inert storage container, not an active interacter. However, in
@@ -398,7 +398,7 @@ A cron job that runs once a night at Faber, scanning a database
 and revoking credentials that have changes status during the day,
 is an agent for Faber. This is true even though it doesn't listen
 for incoming messages (it only talks [revocation protocol](
-https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation) to the ledger). In order to
+https://github.com/hyperledger/indy-hipe/tree/main/text/0011-cred-revocation) to the ledger). In order to
 talk that protocol, it must hold keys delegated by Faber, and it
 is surely Faber's fiduciary.
 

concepts/0020-message-types/README.md

@@ -4,7 +4,7 @@
 - Status: [ACCEPTED](/README.md#accepted)
 - Since: 2019-05-24
 - Status Note:  
-- Supersedes: [HIPE 0021 Message Types](https://github.com/hyperledger/indy-hipe/tree/master/text/0021-message-types)
+- Supersedes: [HIPE 0021 Message Types](https://github.com/hyperledger/indy-hipe/tree/main/text/0021-message-types)
 - Start Date: 2018-07-06
 - Tags: [concept](/tags.md#concept)
 

concepts/0021-didcomm-message-anatomy/README.md

@@ -62,7 +62,7 @@ The most important concepts to introduce about these conventions are the followi
 #### Message Type
 
 Every message contains a message type which allows the context of the message to be established and therefore process the content,
-see [here](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0020-message-types/README.md) for more information. It is also important to
+see [here](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0020-message-types/README.md) for more information. It is also important to
 note that in DIDComm, the message identification does not just identify the message, the message type also identifies the associated protocol. These
 protocols are essentially a group of related messages that are together required to achieve some form of multi-step flow see [here](../0003-protocols/README.md) for more information.
 

concepts/0029-message-trust-contexts/README.md

@@ -133,7 +133,7 @@ MTCs apply to the entirety of the associated message's attributes. However, _emb
 attachments present the unique situation of nested content with the potential for a trust context that differs from the
 parent message.
 
-The [attachment descriptor](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0017-attachments/README.md#embedding),
+The [attachment descriptor](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md#embedding),
 used for both _embedded_ and _appended_ attachments, shares the same MTC as the parent message. Unpacked attachment data
 have their own Trust Contexts populated as appropriate depending on how the data was retrieved, whether the attachment
 is signed, whether an integrity checksum was provided and verified, etc.

concepts/0047-json-ld-compatibility/README.md

@@ -4,7 +4,7 @@
 - Status: [ACCEPTED](/README.md#accepted)
 - Since: 2019-02-20
 - Status Note: Has guided Indy design choices for several months. Not yet ratified by greater Aries community. 
-- Supersedes: [Indy HIPE 0035](https://github.com/hyperledger/indy-hipe/tree/master/text/0035-json-ld-compatibility)
+- Supersedes: [Indy HIPE 0035](https://github.com/hyperledger/indy-hipe/tree/main/text/0035-json-ld-compatibility)
 - Start Date: 2019-01-23
 - Tags: [concept](/tags.md#concept), [decorator](/tags.md#decorator)
 

concepts/0049-repudiation/README.md

@@ -4,7 +4,7 @@
 - Status: [ACCEPTED](/README.md#accepted)
 - Since: 2019-03-01
 - Status Note: Well understood and baked into various protocol designs and DIDComm processes--but not yet ratified by the larger Aries community. 
-- Supersedes: [Indy HIPE 0037]( https://github.com/hyperledger/indy-hipe/tree/master/text/0037-repudiation)
+- Supersedes: [Indy HIPE 0037]( https://github.com/hyperledger/indy-hipe/tree/main/text/0037-repudiation)
 - Start Date: 2018-03-01 (backdated)
 - Tags: [concept](/tags.md#concept)
 

concepts/0050-wallets/README.md

@@ -4,7 +4,7 @@
 - Status: [ACCEPTED](/README.md#accepted)
 - Since: 2018-07-01
 - Status Note: Fully implemented in Indy SDK, but not yet socialized well in the broader Aries community. Needs some updates to promote better key management; see related RFC about [lox](../../features/0042-lox/README.md). 
-- Supersedes: [Indy HIPE 0013]( https://github.com/hyperledger/indy-hipe/tree/master/text/0013-wallets)
+- Supersedes: [Indy HIPE 0013]( https://github.com/hyperledger/indy-hipe/tree/main/text/0013-wallets)
 - Start Date: 2018-05-22
 - Tags: [concept](/tags.md#concept)
 

concepts/0074-didcomm-best-practices/README.md

@@ -398,7 +398,7 @@ to make the content as useful as possible:
 with (possibly) many documents.
 * Hyperlinks from one RFC to another should be in relative form (`../features/my-rfc/README.md`),
 not in absolute form (`/features/my-rfc/README.md`) or external form
-(`https://github.com/hyperledger/aries-rfcs/blob/master/features/my-rfc/README.md`).
+(`https://github.com/hyperledger/aries-rfcs/blob/main/features/my-rfc/README.md`).
 This lets us move or embed the content, and it prevents branch names from
 cluttering the hyperlink.