[Phase-2] HIP-32: Define text to be read for profile renewal

[miguel]

@ludovico

“I certify that I am a real human and that I am re-applying for this registry” by

“I certify that I am a real human and that I am re-applying for this registry”

That’s good

[ludovico]

Ok I’ll leave this a little longer, and I’ll pass it to phase 2. The Snapshot poll will have one “no” and several “yes” (one for each phrase proposed.

I’ll add an internal poll right here to see if we want some proof that the video was not recorded in advance or not.

We should also decide what @fnanni proposed, which is have both phrases allowable in order to reduce challenges.

[ludovico]

Poll 1: Should there be a “time of recording proof” in the renewal video? (newspaper of the day, block hash, etc)

• Yes
• No

Poll 2: should the first submission text be accepted along with the renewal text?

• Yes
• No

[clesaege]

I think the time of recording proof would be a good idea. It could be done instead of the address:

• The address is there to prevent someone from frontrunning a new submission by submitting themselves, but this problem isn’t there in case of renewal.
• There is an additional problem in case of renewal were people could prerecord statements and let their heir keep their profile after they passed away.

In any case, the frontend would need to be updated so that the blockhash they read is shown to them.

[ludovico]

Sounds like a plan, how does this affect the challenger task? I mean since everyone is going to have a different sign, how a challenger is able to check which block hash is the right one? Is the front-end modification feasible?

[ludovico]

Moved to Phase 2

https://snapshot.org/#/poh.eth/proposal/0x46a0d6d234fa2d6028564acfe91b765890a36e00e13987777adeeb4be31baf10

[clesaege]

@ludovico

The renewal procedure will follow the same rules than the registry procedure except:

• The renewer must say <to be defined, see below>. Renewers should speak in their normal voice and should not attempt mimicking someone else’s voice. Speaking before or after the required sentence is acceptable. Poor English accents, mispronunciations, and the switch or oversight of words in that sentence are not grounds for rejections
• The sign should display in a readable manner the <time validation options, se below>

I think the proposal is currently underspecified, so I voted against even if I’m not against the idea.

[ludovico]

If you are not against the idea then I suggest you consider

• Propose what changes are needed (it is the idea of this phase as specified in HIP-5)
• Vote for it, or do not vote. Underspecification is not a valid cause for voting against it at this phase. To me it sounds more sabotage-ist than any other thing.

[ludovico]

Things to solve to move it to Phase-3 if approved:

• [ ] Select which specific phrase is going to be used
• [ ] Propose specific alternatives for time validation
• [ ] Specify which changes would need to be made to the primary document (almost done)
• [ ] Specify which changes would need to be made to the front-end
• [ ] Possibly? Allocate funds for a dev to do the necessary changes

Changes and comments can be added at this hackmd note

[Phase-2] HIP-32: Define text to be read for profile renewal - HackMD

[clesaege]

It’s not sabotage, it’s that currently, this proposal is not specified enough to find out if it is good. We don’t need to move to phase 2 to discuss it. We can just discuss it there and move it to phase 2 when it’s finished. Here the proposal would probably be void as it just says “we’ll determine that later” which would unnecessarily use people attention and create voter fatigue.

[ludovico]

The proposal has been in Phase 1 - Ideation for 11 days now, it was more than enough to give it exposure and feedback.
Nothing against you, but I need to point out that this is not the first time that you personally arrive late to the discussion and just because you just happen to disagree you vote against just to give you more time.

What you are doing is inciting voter fatigue, because the main idea is absolutely there and Signalling vote clearly says “Make no changes”. If you clicked on that button, then you are being inconsistent on what you said, because you just wrote that you were not against this change. This is a true disrespect for the voters themselves and the creation of a new Phase 2 signalling poll would definitely create voter fatigue.

We have a roadmap to Phase 3, and only when the conditions are met, I will submit it to Binding vote.

[clesaege]

Luis, please stop the off topic personal attacks. The proposal is not finished and even if you were to manage to get votes to pass it, it wouldn’t have any effect as it contains “<to be defined, see below>” and “<time validation options, se below>” which are not defined.

We voted HIP-5 exactly to avoid those kind of issues.

@Jrag

Any individual or entity wishing to create a proposal and put it up to vote will need to go through those steps to ensure that its proposal is detailed enough to be voted on and its implementation enforceable.

The phase 2 is for specification

@Jrag

Phase 2: Specification

This phase requires proposals to be posted in a new dedicated thread the DAO category using the Humanity Improvement Proposal (HIP) template. You can create a Humanity Improvement Proposal (HIP) easily by adding the HIP subcategory, after which your draft post will automatically be populated by a HIP template for you to fill in. You can move a proposal to Phase 2 by posting the HIP-# with the phase-2 tag.

The HIP template recommends that all proposals should contain the following fields when applicable , such as a Simple Summary, Abstract, Motivation and Specification.

which this proposal doesn’t contained.

I would therefore advise to withdraw the phase 2, specify it and put it to phase 2 again. As if it were to be voted as it is, it wouldn’t be enforceable.

[ludovico]

You missed a small little discussion which was already settled:

HIP-5: Adopt a proper PoH DAO Governance process to ensure HIP quality

Sorry for the late reply due to my current paternity leave. Indeed, there are no requirements (explicitly expressed in HIP-5) in terms of sequentiality or simultaneousness of editing the proposal thread for phase 3 and submitting the binding proposal vote on Snapshot. Theoretically, you could do both at the same time but I would not recommend it. If you do this, it does not allow for feedback time on your phase 3 post with additional information about the implementation details. This means som…

[clesaege]

Discussions are very different from “voted proposal text”. And even if you could edit it between phase to update/fix minor details, HIP5 still state that phase 2 is for specification. At the current state of your proposal, it is not enough specified to gather my support.

For example, the alternatives for time validation do not look good.

@ludovico

the time when the renewer clicked on the “renew” button.

Is not something that could be assessed.

@ludovico

some periodical reference time in the recent past, for example the midnight UTC of last day, or 00:01:00 UTC of the first day of each month.

Would lead to practical issues to people registering around midnight.

A solution could be to allow for any blockchash within a month (1 month is long enough to be sure the TX would be mined and short enough such that there wouldn’t be incentives to make videos in advance for dead people as it could only lead to abuse if the person were to die within a month).

Another issue would be implementation timing, if this were to be implemented before the UI could be changed, we (the Kleros Cooperative) would have to shut down the renewal UI to prevent people from losing money due to not following the blockhash rule (as the UI should show the blockhash that the user). So this would require a timeframe for implementation (like “after at least 1 POH UI is updated to show the blockhash needed for renewal”).

So I would advise to craft a fully specified proposal and then you would:

• Be more likely to get people support.
• Be sure that it’d be implemented if voted.

[ludovico]

@clesaege

So I would advise to craft a fully specified proposal and then you would:

• Be more likely to get people support.
• Be sure that it’d be implemented if voted.

This is exactly what I am commited to facilitate before Phase-3.
@juanu is working on the specifications and a version of those will be published soon. I think that the hackmd document above shows these changes in real time.

[clesaege]

Despite the fact that this proposal will probably get a majority, it is invalid as it violates HIP-5.

@Jrag

Specification

(Required for Phase 2)

The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow for it to be reasoned about by participants in the PoH DAO.

I would advise updating the proposal to have it specified in order to prevent a governance dispute.

[juanu]

This makes sense to me. @ludovico I believe we can put some work on adding more details to it.

[ludovico]

HIP-32 On Phase 2 has passed. Moving to the roadmap. First item in the agenda:

@ludovico

• [ ] Select which specific phrase is going to be used

There is a relevant discussion in @juanu 's post that could be later integrated into this HIP. A verifiable, time-constrained, frictionless mechanism for Proof of Humanity renewals

[ludovico]

Which phrase should be read for the renewal?

• “I certify that I am a real human and that I am renewing my registration on this registry” by @juanu
• “I certify that I am a real human and that I am re-applying for this registry” by @Koki
• "“I certify that I am a real human, and this is my video for Proof of Humanity.” by @ruben

[0x348f426e73484a07b23265b2cd66e0139f77fc21_Ethereum]

Hi. The phrase I propose for the second (and subsequent) videos in the app is "I certify that I am the same person who previously registered in this registry with this profile. "