I can’t tell what the general flow of the API usage in general is. Am I supposed to login/authorize somehow first? Some common examples, especially in at least one programming language (whether that’s curl or python or whatever) I think would go a long way to help people understand what they’re supposed to do.

This could use indeed some work

How do I know if I need to authorize for a particular endpoint?

openapi spec allows one to specify the authentication, this has not be done already because there is an open issue to include auth in lemmy-js-client (I use this to generate the spec) + Need to figure the best approach to convey "elevated" auth endpoints. Endpoints like GetSite where authentication enhances the response.

Endpoint descriptions are often unhelpful.

They are actually summaries, they are fine imo. There is an open issue to add the descriptions though.

We have to guess what endpoint we might need for a lot of things. Example: /post/like is also for dislikes, but it doesn’t tell you that. It also never tells you HOW to like or dislike anything, the valid values of score do not appear to be documented. And you’re left to assume that’s the right field to even use for it.

Yes indeed, things like this should be documented in the description.

What is the content type of the request supposed to be? JSON is never mentioned anywhere.

This is explicitly mentioned on every request, visually and in the spec.

What are these named “parameters”? Is that a query parameter? Why does it say “object” and “(query)”? Does this parameter go in the request body instead?

Query is mentioned when they are query parameters, else it just a request body. This is pretty clear in the text (spec) or visually imo.

/user shows a parameter called “GetPersonDetails” except in reality this name is (I guess) supposed to be completely ignored, because no part of the request actually uses the string “GetPersonDetails”.

GetPersonDetails is the name of the object if you scroll all the way to the bottom you can inspect it. This more clear in the spec.

Schema is missing for many endpoints, like the request part of /user.

There is not a single endpoint missing nor its requests.

What are all these fields under “GetPersonDetails”? Are they all required? Only some? It doesn’t say anything about it.

This could be improved.

Many of the possible error codes are undocumented.

Status codes? or the 400 lemmy error? ex: { error: "report_reason_required" } Status codes are the same everywhere, 200/201 or 400 with Lemmy error as response. There is one exception that is 401 that can be thrown for every auth required endpoint where auth fails. But these are standard. Ig this should documented.

Now the "LemmyErrorTypes". This could be improved, but it is hard to, not possible to be automated and tedious to add and frequently changes.

Thanks for the feedback.

Ah yes, all though I ve never really experienced HTTP days in their full glory

I'll look into using it. If it has a github action or easy way to publish it from cli

I do not see how critisms for the JS API docs are relevant for my openapi documentation.

This documentation aims to solve all those problems in a language agnostic way. It descibes the endpoints, the request object, the status, the response object, the authentication needed in visual/text. It allows you test it right from the browser, allows you to copy a working curl command, search for endpoints based on keywords, allows you to import the entire spec into postman/alts.

I ve never had any problems with CF instances but I mostly test with voyager.lemmy.ml

Looks like the best openapi front. I looked into using it, but it didn't seem free. Too bad this one is outdated. Lemmys API has changed quiet a bit since then.

(Author btw)

Can you expand on this? This was written for Kotlin usage. It automates generating API based on this spec.

I have no idea what you mean with 'using other approaches to calling the endpoints'

Lemmy has only one API. It's same API used for lemmy-ui.

This is just a "better" documentation for it.

The API works for for cloudfare instances too.

There is also a swagger ui variant

https://mv-gh.github.io/lemmy_openapi_spec/swagger_ui.html

Ah I misunderstood, you want list without the thumbnail at all?

In the feed you can find the post view mode in the top right more options menu.

Yeah anywhere were you would use Java. Scala has a too high adoption cost. Kotlin is better suited for enterprise, has a stronger ecosystem and better interop with Java. I did enjoy scala though when experimented with it. The only thing I missed was the lack of control flow, no labels, continue, break

Yes but now it must wait for acknowledgement of a request (activity), before sending the next one. If one request takes 333ms means you can do max 3 requests per second. Now big instances like lemmy.world have activity above that so instances too far will perpetual lag behind

https://github.com/LemmyNet/lemmy/issues/4529

What's your ping with Lemmy.world?

Mostly because Lemmy has a hard time keeping up with the federation

https://github.com/LemmyNet/lemmy/issues/4529

I genuinely don’t understand how there can be so many languages and all of them be painful to use

What about kotlin?

The swipe gesture feature uses a new experimental component. As far as I am aware we can't configure the sensitivity. We have decided to have it off by default. We also fixed the swipe direction not being aligned with the description.

Probably tommorow

Not really, it would also be hard to implement but I don't think its impossible.

Hardest part is the ID of the same post differs between instances and the post might not exist yet either. I'll create a issue for this feature request.

There is a mark read on scroll setting. When post gets scrolled out of view it will be marked read.

There is a bug that in communityview of an 0.18 instance it will only show first page. It is fixed but not released yet.

Can you expand on this? while you are scrolling it randomly refreshes?

I prefer making the action fully configureable (like even setting to nothing), over having a swap action setting.

Bottom bar collapse exists the other way, some users prefer to not see the bar by default and then you can hold to show the bar.

I definitely wanted to make, tap/hold actions fully configureable. It's somewhere on the backlog, I'll create an issue if it doesn't have it already.

Can you expand on this?

It's more the other way around, some ppl prefered, having the bar collapsed by default. And then hold to reveal it

Not in a way that is easily shareable. Working on a log viewer next.

Can you tell me what broke?

Yeah that would be great but i am not sure if that release includes the logging of HTTPClient, could you try it from latest build?

That's already been fixed, and will be part of 0.0.51

My first attempt, is making a Kotlin multiplatform backwards compatible Lemmy API client. I'll see how it plays out.

Test missing comment please ignore

Alright we will be dropping this feature until we make a proper swipe to exit

Did you try logging in again with that account?

If it keeps happening after that what instance and what account is it?

The full sentence is This account (%s) is being verified

It's verifying that everything is correct, acc not banned, JWT works, instance alive, ...

It only shows that, if you are attempting something that causes it to be verified while already verifiying that account.

Nbd, should ve resolved itself in a few seconds

Can you also test if the problem is still fixed with this build and that the flick to exit works in the ImageViewer

https://github.com/dessalines/jerboa/files/12618555/fix_zooming_jerboa_debug.zip

np

Can you also test if the problem is still fixed with this build and that the flick to exit works in the ImageViewer

https://github.com/dessalines/jerboa/files/12618555/fix_zooming_jerboa_debug.zip

Kotlin is now preffered over Java by Google

https://developer.android.com/kotlin/first

You can still build latest apps using Java and traditional view system. There is still insurmountable of Java apps out there easily eclipsing Kotlin apps.

I prefer Kotlin because the language is so much nicer to write in. Also because the future is moving in this direction.

You can read this GTP summary on why Kotlin over Java. Or find some other dozen articles

::: spoiler summary

Kotlin has become increasingly popular for Android app development for several reasons:

1. Conciseness: Kotlin code is often more concise than equivalent Java code. It reduces boilerplate code, making development faster and less error-prone.

2. Null Safety: Kotlin's type system helps prevent null pointer exceptions, a common issue in Java. This improves app stability and reduces crashes.

3. Interoperability: Kotlin is fully interoperable with Java. You can use Java libraries in Kotlin projects and vice versa, making it easy to transition from Java to Kotlin.

4. Functional Programming: Kotlin supports functional programming constructs, which can lead to more elegant and maintainable code, especially for complex operations.

5. Extension Functions: Kotlin allows you to add new functions to existing classes without modifying their source code. This is useful for enhancing existing Android APIs.

6. Coroutines: Kotlin offers native support for asynchronous programming using coroutines. This simplifies managing background tasks, making your apps more responsive.

7. Default Arguments and Named Parameters: Kotlin allows you to specify default values for function parameters and use named parameters, enhancing code readability.

8. Smart Casts: Kotlin's type system automatically casts types when certain conditions are met, reducing the need for explicit casting in code.

9. Data Classes: Kotlin's data classes simplify the creation of classes meant primarily for storing data, reducing the amount of boilerplate code.

10. Great Tooling: Kotlin is well-supported by Android Studio and offers excellent tooling for Android app development.

While Kotlin offers many advantages, it's essential to consider your team's familiarity with the language and any existing Java codebases. Transitioning from Java to Kotlin can take some time, but many developers find it worthwhile for the benefits it brings to Android app development.

:::

Kotlin doesn't really offer a performance benefit over Java. It's negligible. It's mostly the enchanced type safety.

Kotlin being a requirement really depends on job ur applying for. There is still full Java teams. But imo more are switching to Kotlin. Or taking sorta hybrid approach. Imo Kotlin is great and the only downside i have is that learning it will make you feel annoyed when writing Bloated java again.

There is no real order of which issues get done. Everyone is welcome to contribute any feature/fix they find important.

I just work on things I find have priority which is mostly bugs first. The next big feature is probably backwards compatible API which is a huge amount of work.

There is a issue for the creation of communities. Already but it doesn't specify exactly it. Like where do we add this in UI, do we make a fullblown screen or just a popup. Which logic for showing this creation menu. Some instances don't allow users to make them. etc

They could even fully rebuild it with Jetpack compose (possibly Kotlin even) instead. Will have to build from scratch and use the old codebase as a reference.

Tho be warned Jetpack Compose is not mature yet.

The setting makes it so that it open links in private/incognito tabs. So they won't pollute your browsing history.

This update added support for FireFox. But there seems to be some issues in other browsers. Were you also using Chrome?

Jerboa is just showing you the error it got from your instance. I can look into the source code for Lemmy but that won't be for a while.

"community ban" is not something that is coded into Jerboa as far as I know.

It didn't enable by default in this update. But I think when it did get added it was with default enabled but that was a while ago. I can take look at changing this default.

That issue with firefox is not one caused by Jerboa. So that would need to be reported with FireFox. The only change we did was add support for FireFox.