Vic

I like that the [Uuid crate ](https://docs.rs/uuid/latest/uuid/index.html) has a [Uuid type](https://docs.rs/uuid/latest/uuid/struct.Uuid.html) that just stores the random bytes. If you're planning to change the API, something like this would be nice...

I've been trying to solve this today. The [CryptoJS library](https://cryptojs.gitbook.io/docs/) has support for PBKDF2, there's also a [wrapper for use in Vue](https://www.npmjs.com/package/vue-cryptojs). However, it looks like it's not an easy...

What if the feature is disabled if there is no API key available (by default)? Someone could build a version with an API key and publish it on Google Play....

Looks like most of the code is already there in the `cmd/restic` package and I just need to create a new command to make use of it. If it's ok...

I'm working around this problem by using the [`Route::at`](https://docs.rs/tide/0.16.0/tide/struct.Route.html#method.at) method. ```rust let mut server = tide::new(); server.at("/foo").get(foo_handler); // "nested" server let mut api = server.at("/api"); api.with(auth).with(cors).with(JsonApi); api.at("/endpoint1").get(something); api.at("/endpoint2").get(somethingelse); ``` It...

I've found a single difference between nested servers and this workaround with routes since I've started using it: the moment at which middleware is executed. Middleware on a Server seems...

You're right, I'll update this, thanks!

Some User objects contain only a nickname, so using `getUserName()` is not an option. If more user details are available, banning on hostname will work. I don't think it's necessary...

In that case we need to delay the actual ban command and wait for whois response, but that would work. Another way of doing this is improving the user list...

And currently the ban method doesn't even check if there is information about the user in the userlist. That definitely has to change.