My Api is getting pretty far too. Doing initial integration attempts. Not sure what the timeline is for v0.19. I probably could get it done in 2weeks. Really depends in what problems in run into.

btw this has a good guide for publishing to maven

https://central.sonatype.org/publish/publish-maven/

Cool. Its tough to say yet when we'll release v0.19, definitely not this week, but possibly next week. Obvi I'll make sure jerboa is ready before then. But for now at least I'm just planning on supporting v0.19, considering all the API changes.

If you get your backwards-compatible API done soonish tho, we can use that one instead / in favor.

Also you will have to redo the generate Types thing, there were some changes again

K, addressed some of these above. Re-running copy_generated_types didn't seem to pick up anything new.

BTW I also tested image uploading on voyager.lemmy.ml from this PR (I removed that cookie stuff), and it works.

I was trying to test this PR but voyager seems to be having issues atm. I will test it later

Alright it works but it seems to constantly display, "this account is being verified" on return out of a post. (It should not even be verifying the account)

Using 0.18 accs seems to work better than I expected, I can browse but it does display the verification thingy stuck on jwt (prob cuz that doesn't fall back thus jwt verification fails as auth=null) (Maybe add a version warning? we can keep as is but we will definitely get issues around this)

Using 0.18 accs seems to work better than I expected, I can browse but it does display the verification thingy stuck on jwt (prob cuz that doesn't fall back thus jwt verification fails as auth=null) (Maybe add a version warning? we can keep as is but we will definitely get issues around this)

Where would be the best place to add that toast?

We had one in the root of our app by twiz, but that one is based of getSite which wouldn't work as getSite doesn't work across version. You could reuse it but add that nodeinfo stuff to get version but that's a lotta work. Or you could wait until my api is done.(merge as is, release in the meantime) Or we can use my LemmyApi.getVersion that does functionality but i would have to cut a prelease first.

I'll wait until your API is done, I'll just merge this as is. Again, sry about the conflicts, lmk if there's anything I can do to help there.

The hardest part that I still need to figure out, is that the API instance creation, now is suspended, (has to do a version call) meaning that it has todo that first before any other call, currently it doesn't adhere to that, which causes some race condition issues. As initial getSite / getPosts will done for the default.

Currently the approaches that I can think of are:

• Loading screen, where it inits the api. Don't like this as when it fails the call it should allow the user to still navigate through the app and switch users.
• do something like we do with account everywhere, observe its state and update relevant composables. Don't like this as we would have to do this everywhere
• Make getInstance suspend until it is init. If init fails create default instance, but guess that it is the latest version. If it isn't no problem other calls fails but allows you to switch accounts etc. I prefer this approach. Seems the most ergonomic but I need to figure out the "suspend until init" part.

(3) Makes the most sense to me also. Could be a part of the changeInstance function, which I believe is called on startup, as well as when switching accounts.

While fixing merge conflicts, I found some issues,

• SaveUserSettings no longer returns LoginResponse it Returns successResponse now
• MarkPostResponse no longer returns the post instead successResponse