@arrenv as I start to work through this, one idea I had would be to introduce a "cooldown window" after the applicant cancels their application and before their stake can be reclaimed. This would allow a colony to make a motion to slash their stake, while avoiding a lot of complicated controls around when a user could cancel their application.

@arrenv as I start to work through this, one idea I had would be to introduce a "cooldown window" after the applicant cancels their application and before their stake can be reclaimed. This would allow a colony to make a motion to slash their stake, while avoiding a lot of complicated controls around when a user could cancel their application.

I think that is a good idea, nice one!

I don't feel it is necessary to store the application details on chain in order for a motion to be able to update details.

Can you expand on this? How do I know what I'm voting on if they're are not stored, or at least referenced, on chain?

I don't feel it is necessary to store the application details on chain in order for a motion to be able to update details.

Can you expand on this? How do I know what I'm voting on if they're are not stored, or at least referenced, on chain?

When a Motion is created for the payment, then the details will need to be on chain. I was thinking that prior to this though you could get away with not having to store details on chain while they are still being decided.

@arrenv was talking to @area today and he was wondering how this functionality will look for a decentralized user of the dapp. Specifically, user A puts in a stake to access the incorporation flow, with an application stored on the server. User B is using a decentralized version of the dapp -- will they not be able to see the application? Not see it until the motion has been made? How will the experience translate between centralized and decentralized versions?

I'm not 100% sure how it will be implemented from a technical standpoint, but I am assuming it could be stored in IPFS until the application details are ready to be ratified onchain with the payment request motion. Which would make the experience the same for both versions.

Following up, perhaps the dapp would show any application data stored on IPFS, and reference the extension to decide which apps to render in the UI.

As an update, my thought in approaching this has been to develop a more generic UxGate extension which can be used to implement staking to allow access to various UI features. It would accept a stakeType argument which in this case would be Korporatio or something similar, but could be used for other things. My justification is that there is very little in the contracts that is Korporatio-specific, but seems to be more concerned with using stakes to manage access to UI more broadly.

Update: whether that is a per-stake value, or a configuration parameter for the extension as a whole, is up for discussion.

As an update, my thought in approaching this has been to develop a more generic UxGate extension which can be used to implement staking to allow access to various UI features. It would accept a stakeType argument which in this case would be Korporatio or something similar, but could be used for other things. My justification is that there is very little in the contracts that is Korporatio-specific, but seems to be more concerned with using stakes to manage access to UI more broadly.

Update: whether that is a per-stake value, or a configuration parameter for the extension as a whole, is up for discussion.

I certainly like the idea of a more generic extension for this. It would certainly allow for more flexibility with the same sort of flow in the future.

I feel that given an implementation as a generic extension, it would make sense to make this a configurable parameter. It would give a lot more control for a DAO. It would still be important to have an option that uses the same staking calculation as Motions though, i.e. "Required stake based on individual user's reputation".

@arrenv when slashing a stake, would you like to be able to decide whether or not to remove reputation, as well as the stake? I'm thinking of a logic similar to what we do with stake expenditures.

@arrenv when slashing a stake, would you like to be able to decide whether or not to remove reputation, as well as the stake? I'm thinking of a logic similar to what we do with stake expenditures.

Yes, let's follow the same logic as staking expenditures.

To confirm though, when slashing on an expenditure, in the designs you are choosing to slash or not. There is not a separate one for slashing reputation or not.

However, is that how it works on the contracts? I.e. you can choose to both slash stake and reputation or whatever combination of those two options.

Currently the stake expenditure extension accepts a flag which optionally slashes reputation, as well as stake. We can copy that implementation over, and you can choose whether or not to expose that in the UI, or we can remove it entirely.