This is a series of squashed commits from cysfor @ github.
* Pleroma base62 "flake_id" isn't a decimal integer
* Is it the path order?
Still learning Django, making sure it's not erroring out because the path order is backwards. /user/:id dies saying /user/:id/next/:thingy won't parse, so I thought they might be out of order. But actually the template main/user.html silently recurses when you do /user/:id sending another query for /user/:id/next/:etc.
* I figure out flake_ids
Go figure Pleroma can't even use hexadecimal numbers. Nope, base62 is clearly the way to go. They're working for me, at any rate.
Co-authored-by: Cy <autocommit>
Co-authored-by: Cy <email>
Sometimes Brutaldon thinks it has a valid session key, but the upstream Fediverse server does not, and Brutaldon needs to handle that. Brutal probably should un-set its own internal logged-in state when that happens, but for now it just returns the same thing as if you weren't logged into Brutaldon, making you log in again, making Brutaldon get a new session token from upstream.
Because when you add one field to a class, you clearly want to add two fields to a class, and there's no need to consider the field you never asked to add to be something other than a field.
No need to list the preference fields three times in three places in the code. A class decorator ought to be able to sleuth them out from the model itself. Should make it easier to add new preferences.
Recreate the mastodon object if there's an error complaining about a missing feature set. Only happens for status_post I think. Could be further generalized...
Pleroma will send records that cause brutaldon to make pleroma-specific responses, which the mastodon python module wigs out on claiming it doesn't support that "feature set" so allow for a feature set to be specified...
Jason McBrayer
cyisfor
Cy
Cy
Diana Thayer