Upcoming change to sign-up API

[bocops]

mastodon/mastodon#34495 details upcoming changes to the sign-up API that we should implement on our end. As far as I can tell, in the simplest case we'd need to:

• make min_age available in Instance.Registrations
• add date_of_birth (String, optional) parameter to AccountMethods.registerAccount(...)

Following a decision on how exactly we want to detect problematic requests, we could additionally, later:

• in registerAccount(...), detect if dateOfBirth is null while client.getInstance().registrations.minAge is not, then throw an exception
• make dateOfBirth some date-based type (does a variant of our PrecisionDateTime work here?), then detect if the resulting age would be smaller than the necessary minAge of the connected Mastodon instance.

[PattaFeuFeu]

make dateOfBirth some date-based type (does a variant of our PrecisionDateTime work here?), then detect if the resulting age would be smaller than the necessary minAge of the connected Mastodon instance.

I’ve already added dateOfBirth as a LocalDate now. I get the idea and am somewhat in favour of checking against the minAge but it comes with potential issues:

Time zones
Which time zone do we use for comparison? The local one? GMT? Which one does the server use when comparing?
What if a user is on vacation and we use the local time zone but in the server location, they’re not yet minAge years old because we’re a day ahead in the vacation time zone?

Non-confirmed local time
Client evaluation could be tricked by changing the device running the application’s date and time. I know we only want to catch a few errors early before going over the wire, but we could run into situations where the library let a value past and the server doesn’t—or even worse: the other way round.

---

I think the only checks I would potentially add are for the value of client.getInstance().registrations.minAge. If it’s null, we might as well not pass the birth date—but should be really upfront with library users about that fact.
If it’s non-null but dateOfBirth is, we could throw an exception as you suggest.

[bocops]

Good points all around. I think this and similar conversations always end up in the vicinity of #293 - what level of client-side validation do we want to perform, and #564 - how do we want to handle issues detected during validation. We can revisit the rest of this issue once those discussions have been settled one way or the other.

I don't think that validation on this parameter specifically is really urgent - and I also assume that most library consumers and end users will act in ways that will make errors returned by this endpoint relatively rare. ;)