changes
This commit is contained in:
Alex Grintsvayg
parent
b1fb5f357a
commit
5d10ed6968
2 changed files with 119 additions and 72 deletions
179
index.html
179
index.html
|
|
@ -49,14 +49,19 @@
|
|||
<li><a href="#claim-operations">Claim Operations</a></li>
|
||||
<li><a href="#supports">Supports</a></li>
|
||||
<li><a href="#claimtrie">Claimtrie</a></li>
|
||||
<li><a href="#claim-statuses">Claim Statuses</a>
|
||||
<li><a href="#claim-and-support-statuses">Claim and Support Statuses</a>
|
||||
|
||||
<ul>
|
||||
<li><a href="#accepted">Accepted</a></li>
|
||||
<li><a href="#abandoned">Abandoned</a></li>
|
||||
<li><a href="#active">Active</a></li>
|
||||
<li><a href="#controlling">Controlling</a></li>
|
||||
<li><a href="#claim-controlling-example">Claim Controlling Example</a></li>
|
||||
</ul></li>
|
||||
<li><a href="#claimtrie-transitions">Claimtrie Transitions</a>
|
||||
|
||||
<ul>
|
||||
<li><a href="#determining-active-claims">Determining Active Claims</a></li>
|
||||
<li><a href="#claim-transition-example">Claim Transition Example</a></li>
|
||||
</ul></li>
|
||||
<li><a href="#normalization">Normalization</a></li>
|
||||
</ul></li>
|
||||
|
|
@ -73,7 +78,7 @@
|
|||
<li><a href="#claimsequence">ClaimSequence</a></li>
|
||||
<li><a href="#bidposition">BidPosition</a></li>
|
||||
<li><a href="#channelname-and-claimname">ChannelName and ClaimName</a></li>
|
||||
<li><a href="#example">Example</a></li>
|
||||
<li><a href="#examples">Examples</a></li>
|
||||
</ul></li>
|
||||
<li><a href="#design-notes">Design Notes</a></li>
|
||||
</ul></li>
|
||||
|
|
@ -213,7 +218,7 @@
|
|||
<dl>
|
||||
<dt>stream</dt>
|
||||
<dd>Declares the availability, access method, and publisher of a stream of bytes (typically a file).</dd>
|
||||
<dt>identity</dt>
|
||||
<dt>channel</dt>
|
||||
<dd>Creates a trustful pseudonym that can be used to identify the origin of stream claims.</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -229,7 +234,7 @@
|
|||
<dt>amount</dt>
|
||||
<dd>A quantity of tokens used to stake the claim. See [Controlling](#controlling).</dd>
|
||||
<dt>value</dt>
|
||||
<dd>Metadata about a piece of content or an identity. See [Metadata](#metadata).</dd>
|
||||
<dd>Metadata about a stream or a channel. See [Metadata](#metadata).</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
|
|
@ -274,7 +279,7 @@
|
|||
|
||||
<p>A <em>support</em> is an additional transaction type that lends its <em>amount</em> to an existing claim.</p>
|
||||
|
||||
<p>A support contains a claim ID, and amount, and nothing else. Supports function analogously to claims in terms of <a href="#claim-operations">Claim Operations</a> and <a href="#claim-statuses">Claim Statuses</a>.</p>
|
||||
<p>A support contains a claim ID, and amount, and nothing else. Supports function analogously to claims in terms of <a href="#claim-operations">Claim Operations</a> and <a href="#claim-statuses">Claim Statuses</a>, with the exception that they cannot be updated.</p>
|
||||
|
||||
<h4 id="claimtrie">Claimtrie</h4>
|
||||
|
||||
|
|
@ -290,25 +295,29 @@
|
|||
|
||||
<p>For more details on the specific claimtrie implementation, see <a href="https://github.com/lbryio/lbrycrd/blob/master/src/claimtrie.cpp">the source code</a>.</p>
|
||||
|
||||
<h4 id="claim-statuses">Claim Statuses</h4>
|
||||
<h4 id="claim-and-support-statuses">Claim and Support Statuses</h4>
|
||||
|
||||
<!-- done -->
|
||||
<!-- fix me? is using claims to mean claims and supports okay? -->
|
||||
|
||||
<p>A claim can have one or more the following statuses at a given block.</p>
|
||||
<p>All claims and supports can have one or more the following statuses at a given block.</p>
|
||||
|
||||
<p>Throughout this section, whenever we write claim, we refer to both claims and supports.</p>
|
||||
|
||||
<h5 id="accepted">Accepted</h5>
|
||||
|
||||
<!-- done -->
|
||||
|
||||
<p>An <em>accepted</em> claim is one that has been entered into the blockchain. This happens when the transaction containing the claim is included in a block.</p>
|
||||
<p>An <em>accepted</em> claim is one that has been been entered into the blockchain. This happens when the transaction containing it is included in a block.</p>
|
||||
|
||||
<p>Accepted claims do not appear in or affect the claimtrie state until they are <a href="#active">Active</a>.</p>
|
||||
|
||||
<p>The sum of the amount of a claim and all accepted supports is called the <em>total amount</em>.</p>
|
||||
|
||||
<h5 id="abandoned">Abandoned</h5>
|
||||
|
||||
<!-- done -->
|
||||
|
||||
<p>An <em>abandoned</em> claim is one that was withdrawn by its creator. Spending a transaction that contains a claim will cause that claim to become abandoned.</p>
|
||||
<p>An <em>abandoned</em> claim is one that was withdrawn by its creator or current owner. Spending a transaction that contains a claim will cause that claim to become abandoned.</p>
|
||||
|
||||
<p>Abandoned claims are no longer stored in the claimtrie.</p>
|
||||
|
||||
|
|
@ -316,36 +325,29 @@
|
|||
|
||||
<h5 id="active">Active</h5>
|
||||
|
||||
<!-- done -->
|
||||
<!-- fix me a lot -->
|
||||
|
||||
<p>An <em>active</em> claim is an accepted and non-abandoned claim that has been in the blockchain long enough to be activated. The length of time required is called the <em>activation delay</em>.</p>
|
||||
<p>An <em>active</em> claim is an accepted and non-abandoned claim that has been in the blockchain for an algorithmically determined number of blocks. This length of time required is called the <em>activation delay</em>.</p>
|
||||
|
||||
<p>The activation delay depends on the claim operation, the height of the current block, and the height at which the claimtrie state for that name last changed.</p>
|
||||
<p>If the claim is an update to an already active claim, is the first claim for a name, or does not affect the sort order at the leaf for a name, the activation delay is 0 (i.e. the claim becomes active in the same block it is accepted).</p>
|
||||
|
||||
<p>If the claim is an update to an already active claim, is the first claim for a name, or does not affect the sort order at the leaf for a name, the claim becomes active as soon as it is accepted. Otherwise it becomes active at the block heigh determined by the following formula:</p>
|
||||
<p>Otherwise, the activation delay is determined by a formula covered in <a href="#claimtrie-transitions">Claimtrie Transitions</a>. The formula’s variable inputs are the height of the current block, the height at which the claim was accepted, and the height at which the relevant claimtrie state for the name being considered last changed.</p>
|
||||
|
||||
<pre><code>C + min(4032, floor((H-T) / 32))
|
||||
</code></pre>
|
||||
|
||||
<p>Where:</p>
|
||||
|
||||
<ul>
|
||||
<li>C = claim height (height when the claim was accepted)</li>
|
||||
<li>H = current height</li>
|
||||
<li>T = takeover height (the most recent height at which the claimtrie state for the name changed)</li>
|
||||
</ul>
|
||||
|
||||
<p>In plain English, the delay before a claim becomes active is equal to the claim’s height minus height of the last takeover, divided by 32. The delay is capped at 4032 blocks, which is 7 days of blocks at 2.5 minutes per block (our target block time). The max delay is reached 224 (7x32) days after the last takeover.</p>
|
||||
|
||||
<p>The purpose of this delay function is to give long-standing claimants time to respond to changes, while still keeping takeover times reasonable and allowing recent or contentious claims to change state quickly.</p>
|
||||
<p>The sum of the amount of an active claim and all active supports is called it’s <em>effective amount</em>. Only the effective amount affects the sort order of a claimtrie leaf.</p>
|
||||
|
||||
<h5 id="controlling">Controlling</h5>
|
||||
|
||||
<!-- done -->
|
||||
|
||||
<p>A <em>controlling</em> claim is the active claim that has the highest total effective amount, which is the sum of its own amount and the amounts of all of its <a href="#supports">supports</a>.</p>
|
||||
<p>A <em>controlling</em> claim is the active claim that is first in the sort order at a leaf. That is, it has the highest total effective amount of all claims with the same name.</p>
|
||||
|
||||
<p>Only one claim can be controlling for a given name at a given block. To determine which claim is controlling for a given name at a given block, the following algorithm is used:</p>
|
||||
<p>Only one claim can be controlling for a given name at a given block.</p>
|
||||
|
||||
<h4 id="claimtrie-transitions">Claimtrie Transitions</h4>
|
||||
|
||||
<!-- fix me -->
|
||||
|
||||
<p>To determine the sort order of a claimtrie leaf, the following algorithm is used:</p>
|
||||
|
||||
<ol>
|
||||
<li><p>For each active claim for the name, add up the amount of the claim and the amount of all the active supports for that claim.</p></li>
|
||||
|
|
@ -359,7 +361,26 @@
|
|||
|
||||
<p>The purpose of 3 is to handle the case when multiple competing claims are made on the same name in different blocks, and one of those claims becomes active but another still-inactive claim has the greatest amount. Step 3 will cause the greater claim to also activate and become the controlling claim.</p>
|
||||
|
||||
<h6 id="claim-controlling-example">Claim Controlling Example</h6>
|
||||
<h5 id="determining-active-claims">Determining Active Claims</h5>
|
||||
|
||||
<p>If a claim does not become active immediately, it becomes active at the block heigh determined by the following formula:</p>
|
||||
|
||||
<pre><code>C + min(4032, floor((H-T) / 32))
|
||||
</code></pre>
|
||||
|
||||
<p>Where:</p>
|
||||
|
||||
<ul>
|
||||
<li>C = claim height (height when the claim was accepted)</li>
|
||||
<li>H = current height</li>
|
||||
<li>T = takeover height (the most recent height at which the relevant claimtrie state for the name changed)</li>
|
||||
</ul>
|
||||
|
||||
<p>In written form, the delay before a claim becomes active is equal to the claim’s height minus height of the last takeover, divided by 32. The delay is capped at 4032 blocks, which is 7 days of blocks at 2.5 minutes per block (our target block time). The max delay is reached 224 (7x32) days after the last takeover.</p>
|
||||
|
||||
<p>The purpose of this delay function is to give long-standing claimants time to respond to changes, while still keeping takeover times reasonable and allowing recent or contentious claims to change state quickly.</p>
|
||||
|
||||
<h6 id="claim-transition-example">Claim Transition Example</h6>
|
||||
|
||||
<!-- done -->
|
||||
|
||||
|
|
@ -390,41 +411,30 @@
|
|||
|
||||
<!-- done -->
|
||||
|
||||
<p>Names in the claimtrie are normalized to avoid confusion due to Unicode equivalence or casing. All names are normalized using the NFD normalization form, then lowercased using the en_US locale.</p>
|
||||
<p>Names in the claimtrie are normalized to avoid confusion due to Unicode equivalence or casing. All names are converted using <a href="http://unicode.org/reports/tr15/#Norm_Forms">Unicode Normalization Form D</a> (NFD), then lowercased using the en_US locale when possible.</p>
|
||||
|
||||
<h3 id="urls">URLs</h3>
|
||||
|
||||
<p>URLs are human-readable references to claims. All URLs contain a name, and can be resolved to a specific claim for that name. The ultimate purpose of much of the claim design, including controlling claims and the claimtrie structure, is to provide human-readable URLs that can be trustfully resolved by clients that have don’t have a full copy of the blockchain.</p>
|
||||
<!-- fix me - @grin does SPV need a mention inside of the document? -->
|
||||
|
||||
<p>URLs are human-readable references to claims. All URLs:</p>
|
||||
|
||||
<ol>
|
||||
<li>must contain a name (see <a href="#claim-properties">Claim Properties</a>)</li>
|
||||
<li>and resolve to a single, specific claim for that name</li>
|
||||
</ol>
|
||||
|
||||
<p>The ultimate purpose of much of the claim and blockchain design is to provide human-readable URLs that can be trustfully resolved by clients that have don’t have a full copy of the blockchain (i.e. <a href="https://lbry.tech/glossary#spv">Simplified Payment Verification</a> wallets).</p>
|
||||
|
||||
<h4 id="components">Components</h4>
|
||||
|
||||
<p>A URL is a name with one or more modifiers. A bare name on its own will resolve to the controlling claim at the latest block height, for reasons covered in <a href="#design-notes">Design Notes</a>. Common URL structures are:</p>
|
||||
<!-- done -->
|
||||
|
||||
<p>A URL is a name with one or more modifiers. A bare name on its own will resolve to the <a href="#controlling">controlling claim</a> at the latest block height. Common URL structures are:</p>
|
||||
|
||||
<p><strong>Stream Claim Name:</strong> a basic claim for a name</p>
|
||||
|
||||
<pre><code>lbry://meet-LBRY
|
||||
</code></pre>
|
||||
|
||||
<p><strong>Claim ID:</strong> a claim for this name with this claim ID (does not have to be the controlling claim). Partial prefix matches are allowed.</p>
|
||||
|
||||
<pre><code>lbry://meet-LBRY#7a0aa95c5023c21c098
|
||||
lbry://meet-LBRY#7a
|
||||
</code></pre>
|
||||
|
||||
<p><strong>Claim Sequence:</strong> the Nth claim for this name, in the order the claims entered the blockchain. N must be a positive number. This can be used to determine which claim came first, rather than which claim has the most support.</p>
|
||||
|
||||
<pre><code>lbry://meet-LBRY:1
|
||||
</code></pre>
|
||||
|
||||
<p><strong>Bid Position:</strong> the Nth claim for this name, in order of most support to least support. N must be a positive number. This is useful for resolving non-winning bids in bid order, e.g. if you want to list the top three winning claims in a voting contest or want to ignore the activation delay.</p>
|
||||
|
||||
<pre><code>lbry://meet-LBRY$2
|
||||
lbry://meet-LBRY$3
|
||||
</code></pre>
|
||||
|
||||
<p><strong>Query Params:</strong> extra parameters (reserved for future use)</p>
|
||||
|
||||
<pre><code>lbry://meet-LBRY?arg=value+arg2=value2
|
||||
<pre><code>lbry://meet-lbry
|
||||
</code></pre>
|
||||
|
||||
<p><strong>Channel Claim Name:</strong> a claim for a channel</p>
|
||||
|
|
@ -434,7 +444,32 @@ lbry://meet-LBRY$3
|
|||
|
||||
<p><strong>Channel Claim Name and Stream Claim Name:</strong> URLS with a channel and a stream claim name are resolved in two steps. First the channel is resolved to get the appropriate claim for that channel. Then the stream claim name is resolved to get the appropriate claim from among the claims in the channel.</p>
|
||||
|
||||
<pre><code>lbry://@lbry/meet-LBRY
|
||||
<pre><code>lbry://@lbry/meet-lbry
|
||||
</code></pre>
|
||||
|
||||
<p><strong>Claim ID:</strong> a claim for this name with this claim ID (does not have to be the controlling claim). Partial prefix matches are allowed (see <a href="#resolution">Resolution</a>).</p>
|
||||
|
||||
<pre><code>lbry://meet-lbry#7a0aa95c5023c21c098
|
||||
lbry://meet-lbry#7a
|
||||
lbry://@lbry#3f/meet-lbry
|
||||
</code></pre>
|
||||
|
||||
<p><strong>Claim Sequence:</strong> the Nth claim for this name, in the order the claims entered the blockchain. N must be a positive number. This can be used to determine which claim came first, rather than which claim has the most support.</p>
|
||||
|
||||
<pre><code>lbry://meet-lbry:1
|
||||
lbry://@lbry:1/meet-lbry
|
||||
</code></pre>
|
||||
|
||||
<p><strong>Bid Position:</strong> the Nth claim for this name, in order of most support to least support. N must be a positive number. This is useful for resolving non-winning bids in bid order, e.g. if you want to list the top three winning claims in a voting contest or want to ignore the activation delay.</p>
|
||||
|
||||
<pre><code>lbry://meet-lbry$2
|
||||
lbry://meet-lbry$3
|
||||
lbry://@lbry$2/meet-lbry
|
||||
</code></pre>
|
||||
|
||||
<p><strong>Query Params:</strong> extra parameters, reserved for future use</p>
|
||||
|
||||
<pre><code>lbry://meet-lbry?arg=value+arg2=value2
|
||||
</code></pre>
|
||||
|
||||
<h4 id="grammar">Grammar</h4>
|
||||
|
|
@ -479,7 +514,7 @@ Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
|
|||
|
||||
<h4 id="resolution">Resolution</h4>
|
||||
|
||||
<p>URL <em>resolution</em> is the process of translating a URL into a [[claim ID]].</p>
|
||||
<p>URL <em>resolution</em> is the process of translating a URL into it’s associated claim id and metadata.</p>
|
||||
|
||||
<h5 id="no-modifier">No Modifier</h5>
|
||||
|
||||
|
|
@ -499,13 +534,13 @@ Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
|
|||
|
||||
<h5 id="channelname-and-claimname">ChannelName and ClaimName</h5>
|
||||
|
||||
<!-- fix me: explain how claim signing works, and what it means to be **in** a channel -->
|
||||
|
||||
<p>If both a channel name and a claim name is present, resolution happens in two steps. First, remove the <code>/</code> and <code>StreamClaimNameAndModifier</code> from the path, and resolve the URL as if it only had a <code>ChannelClaimNameAndModifier</code>. Then get the list of all claims in that channel. Finally, resolve the <code>StreamClaimNameAndModifier</code> as if it was its own URL, but instead of considering all claims, only consider the set of claims in the channel.</p>
|
||||
|
||||
<p>Note: claims in a channel are stream claims, so they compete for the non-channel name too. fixme: Expand on this</p>
|
||||
<p>Technically, if multiple claims for the same name exist inside the same channel, they are resolved via the same resolution rules applied entirely within the sub-scope of the channel. Pragmatically, it rarely makes sense for channels to use the same name twice and support for this functionality may be unreliable in current tooling.</p>
|
||||
|
||||
<p>( fixme: explain how claim signing works, and what it means to be <strong>in</strong> a channel )</p>
|
||||
|
||||
<h5 id="example">Example</h5>
|
||||
<h5 id="examples">Examples</h5>
|
||||
|
||||
<p>Suppose the following names were claimed in the following order:</p>
|
||||
|
||||
|
|
@ -686,11 +721,21 @@ Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
|
|||
|
||||
<h4 id="design-notes">Design Notes</h4>
|
||||
|
||||
<p>Most existing public name schemes are first-come, first-serve. This leads to several bad outcomes. When the system is young, users are incentivized to register common names even if they don’t intend to use them, in hopes of selling them to the proper owner in the future for an exorbitant price. In a centralized system, the authority may allow for appeals to reassign names based on trademark or other common use reasons. There may also be a process to “verify” that a name belongs to the entity you think it does (e.g. Twitter’s verified accounts). Such processes are often arbitrary, change over time, involve significant transaction costs, and may still lead to names being used in ways that are contrary to user expectation (e.g. <a href="http://nissan.com">nissan.com</a> is not what you’d expect).</p>
|
||||
<p>The most contentious aspect of this design has been the choice to resolve naked names (sometimes called <em>vanity names</em>) to the claim with the largest number of staked credits.</p>
|
||||
|
||||
<p>In a decentralized system, such approaches are not possible, so name squatting is especially dangerous (see Namecoin). Instead, LBRY creates an efficient allocation of names via a market. Following <a href="https://en.wikipedia.org/wiki/Coase_theorem">Coase</a>, we believe that if the rules for name ownership and exchange are clearly defined, transaction costs are low, and there is no information asymmetry, then control of URLs will flow to their highest-valued use.</p>
|
||||
<p>First, it is important to note the problems in existing domain allocation design. Most existing public name schemes are first-come, first-serve with a fixed price. This leads to several bad outcomes:</p>
|
||||
|
||||
<p>Note that only vanity URLs (i.e. URLs without a ClaimID or or ClaimSequence modifier) have this property. Permanent URLs like <code>lbry://myclaimname#abc</code> exist and are available for the small cost of issuing a <code>create</code> claim transactions.</p>
|
||||
<ol>
|
||||
<li><p>Speculation and extortion. Entrepreneurs are incentivized to register common names even if they don’t intend to use them, in hopes of selling them to the proper owner in the future for an exorbitant price. While speculation in general can have positive externalities, in this case it is pure value extraction. It also harms the user experience of users, who will see the vast majority of URLs sitting unused (c.f. Namecoin).</p></li>
|
||||
|
||||
<li><p>Bureaucracy and transaction costs. While a centralized system can allow for an authority to use a process to reassign names based on trademark or other common use reasons, this system is also imperfect. Most importantly, it is a censorship point and an avenue for complete exclusion. Additionally, such processes are often arbitrary, change over time, involve significant transaction costs, and <em>still</em> lead to names being used in ways that are contrary to user expectation (e.g. <a href="http://nissan.com">nissan.com</a>).</p></li>
|
||||
|
||||
<li><p>Inefficencies from price controls. Any system that does not allow a price to float completely freely creates inefficiencies. If the set price is too low, we facilitate speculation and rent-seeking. If the price is too high, we see people excluded from a good that it would otherwise be beneficial for them to purchase.</p></li>
|
||||
</ol>
|
||||
|
||||
<p>Thus, we need an algorithmic design built into consensus that allows URLs to flow to their highest valued use. Following <a href="https://en.wikipedia.org/wiki/Coase_theorem">Coase</a>, this design allows for clearly defined rules, low transaction costs, and no information asymmetry, ensuring minimal inefficiency in URL allocation.</p>
|
||||
|
||||
<p>It’s also important to note that <em>only</em> vanity URLs have this property. Extremely short, memorable URLs like <code>lbry://myclaimname#a</code> exist and are available for the minimal cost of issuing a transaction.</p>
|
||||
|
||||
<h3 id="transactions">Transactions</h3>
|
||||
|
||||
|
|
|
|||
12
index.md
12
index.md
|
|
@ -52,12 +52,14 @@ TODO:
|
|||
* [Claim Operations](#claim-operations)
|
||||
* [Supports](#supports)
|
||||
* [Claimtrie](#claimtrie)
|
||||
* [Claim Statuses](#claim-statuses)
|
||||
* [Claim and Support Statuses](#claim-and-support-statuses)
|
||||
* [Accepted](#accepted)
|
||||
* [Abandoned](#abandoned)
|
||||
* [Active](#active)
|
||||
* [Controlling](#controlling)
|
||||
* [Claim Controlling Example](#claim-controlling-example)
|
||||
* [Claimtrie Transitions](#claimtrie-transitions)
|
||||
* [Determining Active Claims](#determining-active-claims)
|
||||
* [Claim Transition Example](#claim-transition-example)
|
||||
* [Normalization](#normalization)
|
||||
* [URLs](#urls)
|
||||
* [Components](#components)
|
||||
|
|
@ -68,7 +70,7 @@ TODO:
|
|||
* [ClaimSequence](#claimsequence)
|
||||
* [BidPosition](#bidposition)
|
||||
* [ChannelName and ClaimName](#channelname-and-claimname)
|
||||
* [Example](#example)
|
||||
* [Examples](#examples)
|
||||
* [Design Notes](#design-notes)
|
||||
* [Transactions](#transactions)
|
||||
* [Operations and Opcodes](#operations-and-opcodes)
|
||||
|
|
@ -371,7 +373,7 @@ Names in the claimtrie are normalized to avoid confusion due to Unicode equivale
|
|||
|
||||
### URLs
|
||||
|
||||
<!-- fix me - @grin does SPV need a mention inside of the document? ->
|
||||
<!-- fix me - @grin does SPV need a mention inside of the document? -->
|
||||
|
||||
URLs are human-readable references to claims. All URLs:
|
||||
|
||||
|
|
@ -497,7 +499,7 @@ Get all claims for the claim name. Sort the claims in descending order by total
|
|||
|
||||
##### ChannelName and ClaimName
|
||||
|
||||
<!-- fix me: explain how claim signing works, and what it means to be **in** a channel ->
|
||||
<!-- fix me: explain how claim signing works, and what it means to be **in** a channel -->
|
||||
|
||||
If both a channel name and a claim name is present, resolution happens in two steps. First, remove the `/` and `StreamClaimNameAndModifier` from the path, and resolve the URL as if it only had a `ChannelClaimNameAndModifier`. Then get the list of all claims in that channel. Finally, resolve the `StreamClaimNameAndModifier` as if it was its own URL, but instead of considering all claims, only consider the set of claims in the channel.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue