Insentives + allow `Authorizer` to be a account/location from pallet-revive

[BigTava]

Description

The best way to explain this is by outlining the system flow we envision for the HackM3 prototype:

1. The user registers by calling registerKeys
2. The smart contract then calls pallet_xcm::send(Location(2, PolkadotBulletin), XCM(UnpaidExecution, Transact(bulletin::authorize(user)))).
3. The user subsequently calls bulletin::store() for regular operations.

Motivation

To align with a Web3 architecture, the authorizer should be either a program or the PeopleChain, which would authorize users after verifying their identities. If the latter, how can we, as dApp developers, top up the storage availability?

[bkontur]

how can we, as dApp developers, top up the storage availability?

Exactly, this is the (very good) question, we need to figure out the incentives and quota management strategy for dApps. Probably, smart contracts cannot infinitely allow to top up storage for user, it should be bounded some how - maybe some deposit or something.

[bkontur]

Let's say we have and bulletin-westend parachain and we have AssetHub with mentioned smartcontract mentioned in the desc.

So, AH will communicate with Bulletin parachain over HRMP/XCMP.

@raymondkfcheung please, check and investigate:

• When this smart contract from AH sends the XCM(Transact(OriginKind::Xcm, [UnpaidExecution, Transact(bulletin::authorize(user)])) to the sibling parachain, what would be the resolved origin on the Bulletin side? (it should pass the XcmPassthrough)
• How could we allow and set the resolved origin for type Authorizer = EnsureRoot<Self::AccountId>; https://github.com/paritytech/polkadot-bulletin-chain/pull/83/files#diff-35326eca5649c58c9518ea80de4965d7ce3edae3e9ed3b7ec88f52284bb0e6c0R347 (we could add EnsureXcm<Equals..)

Let's assume everything is "for free" and UnpaidExecution, we need to start somewhere and we will find out paid scenario later

[BigTava]

@bkontur I also leave the suggestion of bulletin::authorize(user) in people-lite::attest?

[bkontur]

@bkontur I also leave the suggestion of bulletin::authorize(user) in people-lite::attest?

I don't know the whole process, how and where is the attest working.
But I would not add bulletin::authorize directly to the attest, I would suggest to implement ConsumerRegistrar callback (needs tuple support), which is called here: https://github.com/paritytech/individuality-public/blob/16fd57601bb7b3737514d2b15a2d49498acb9a07/pallets/people-lite/src/lib.rs#L322,
and bulletin support when configuring here: https://github.com/paseo-network/runtimes/blob/f885d948aa3c189541638721de4762ea5aa7349b/system-parachains/people-paseo/src/people.rs#L345C31-L345C40

type LiteConsumerRegistrar = (Resources, BulletinRegistrar);