Joe Caputo

Thanks to @shannonwells for helping me realize that this is indeed an issue worth raising.

Implementation notes: * Currently, names are loosely/optionally associated with a schema. In order to implement protocol-level delegation, schema names would become a mandatory part of schema creation/deployment. * Currently, extrinsics...

I'm in favor of 4. DSNP content should be unambiguous regarding context; ie, if context is important, then it should contribute to the content hash. 3 seems less desirable because...

So: user-initiated moderation: * Providers should not display moderated content in the context of my thread * content _may_ still be visible in the poster's timeline, for instance. * depending...

Note, as of this time, upstream `polkadot-sdk@stable-2503` crates are only validated against Rust 1.84.1

@shannonwells is the idea here that the following is too cumbersome? ```javascript const info = await apiPromise.query.capacity.stakingTargetLedger.entries( getUnifiedAddress(stakeKeys) ); info.map(([key, value]) => console.log(key.toHuman(), value.toHuman())); ``` sample results: ```console [ '5CPZEZg2A9PMKidzCAoADjjGYJYCwNvM87gnU3uboLbfweTK',...

Additional thoughts: This issue is not so much a bug as an inconvenience. - For publishing, we're always interested in the state at the current block, which we always have,...

# TL;DR Since, for the majority of cases, posted content would fall within the bounds of a _currently in force_ or _recently revoked_ delegation, adding the `granted_at` block number would...

> I went looking for the original delegation design discussions around why we chose to not support gaps. I was unable to find it, but here's the summary I remember:...

> [@JoeCap08055](https://github.com/JoeCap08055) so you are suggesting that we store the granted at block, but effectively never change it. > Not quite. I'm suggesting that we store the `granted_at` block for...