Good question, and to be clear: the RFC doesn't set an 80% cutoff. That number isn't in the draft. It says "mostly" on purpose and lists the exact method and cap as an open question (#8), because we have no empirical failure data to justify a number. The plan is to avoid a hard cutoff: weight edges continuously and calibrate by simulation against two cases, a closed fake cluster (attack) and dense benign clusters like meetups or DAOs. The failure we most want to measure is false positives on real communities. If you know of data or papers on WoT attacks, pointers welcome.

Thanks, this is exactly the weak spot. Two signatures only prove two keys agree, not that two independent people met. We're adding a collusion-resistance requirement to RFC-0017's WoT module: down-weight closed groups of that mostly co-sign each other, cap the reputation a closed group can create on its own, and make your regression test (how much can a fake guest/host pair manufacture before it needs outside trust?) a release condition. Credited in the Discussion section.

Agreed, the AI label is the one line that can't be negotiable. Kept as is.

Good point on signed, timestamped inputs so a host can later prove what the agent saw at booking time. We're adding it as an optional audit feature, with the constraint that inputs contain npub relationships, so they're shared only with the parties involved, not published. We're not integrating any third-party service in this RFC.