Don't require searches by IPv6 address to start with [

Searches by IPv6 address need to include [], and partial searches need to start with [. Example: "[2001:858:2:2:aabb:0:563b:1526]". That's not as intuitive as it could be. We should consider making the [] part optional for IPv6 searches. Not sure if that's a good idea, but I can't come up with major arguments against it.

This enhancement request originates from #10128 (moved) and has low priority.

changed milestone to %Onionoo-1.2.0

added component::metrics/onionoo milestone::Onionoo-1.2.0 priority::very low resolution::fixed severity::normal status::closed type::enhancement labels

I still didn't come up with reasons against making this change, so I wrote a patch.

The only catch is that we're changing the semantics of the current search parameter, because a search for, say "2001", might now return even more relays: matching hex fingerprint starts, matching base64 fingerprint starts, matching nickname parts, and matching IPv6 address starts. Admitted, it's a tiny change, but it's a change. That's why we should do the major-protocol-update dance where we announce a change 1 month in advance, set next_major_version_scheduled, and merge 1 month later. But before we start that dance, let's get the patch ready for merge.

Please review my task-16552 branch.

Trac:
Sponsor: N/A to N/A
Severity: N/A to Normal
Status: new to needs_review
Reviewer: N/A to N/A

Looks fine and has tests :-)

So, the reason for raising the major protocol number is that a search for 0815 could now return all relays having ipv6 addresses starting with the search string? Clients supporting 3.1 shouldn't break, b/c of this change. In a way I would count loosening the restriction on searching for ipv6 addresses to adding a new fields. Thus, this could be in 3.2-1.1.0?

Merge ready, but I would say this change doesn't warrant protocol version 4.0.

Trac:
Status: needs_review to merge_ready

Thanks for looking! :)

But not raising the protocol version to 4.0 feels wrong. We are changing the most important parameter by returning potentially more results than previously. That won't break clients, but it might confuse users. In a way, protocol changes leading to 2.0 and to 3.0 were comparable to this one: in both cases we returned potentially more results than before. Those are major protocol changes, because clients either need to adapt or decide they don't care. That's different from minor protocol version updates which clients can ignore if they wish without even looking.

I'll keep this as merge_ready until we tag the next release, in which case I'll commit a placeholder for version 4.0 and set next_major_version_scheduled to 1 month later.

Assigning to the next milestone, so that we don't forget to start dancing when we put out that release.

Trac:
Milestone: N/A to Onionoo 3.2-1.1.0

Trac:
Milestone: Onionoo 3.2-1.1.0 to Onionoo-1.2.0

I just rebased this branch to current master and prepared the release that is scheduled for next Tuesday. The new branch is task-16552-3. Feel free to review that branch once more before I merge it next Tuesday, but I'll also ask you to review the release before it goes out. Thanks!

Trac:
Status: merge_ready to needs_review

Pushed to master, now preparing the release for later today. Closing. Thanks!

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #20047 (moved)