Aim for ruby-jwt 3.x

[anakinj]

The gem has accumulated a bunch of great features over the years but with the consequence that it has gotten a little bloated.

The biggest challenge so far has been to preserve the backwards compatibility and to do that there is a lot of logic in the code to achieve that.

Now my suggestion is that we would try to document all the things that we would like to see changing to make the gem a nice and maintainable package for dealing with tokens.

One of the biggest challenges is probably the JWT.decode and JWT.encode APIs, how will those look in the future?

A few good pointers brought up here: #528

Tried to group things that could be made under the Version 3.x milestone.

Not sure yet how we could do bigger changes like this, maybe a dedicated 3.x branch that can be a little unstable for a while?

A few things that could help in doing bigger changes:

• Well documented breaking changes in a UPGRADING.md file
• Warnings in previous versions about method getting removed
• Releasing pre versions of the next major version

[WriterZephos]

We need support for unencoded or detached payloads. I am working on those changes, but I am new to the project so I welcome any help/support.

[anakinj]

Appreciate your work so far on #309. The problem as you probably noticed is that the code is not really that extendable and ends up very "if-elsy".

Been working on the 3.0 version in bursts. I pushed the work so far into the branch https://github.com/jwt/ruby-jwt/tree/version-3.0.

The main API has not changed at all (yet at least) But in the background the signing/verifying is very much different.

For this use case the functionality could be it's separate definition of handling tokens:

DetatchedEncoder = ::JWT.define do
  # define how to handle payload/token and headers here
end

No documentation yet on the functionality, have been kinda focusing on making the changes backwards compatible (except for the changes mentioned in the changlog)

[WriterZephos]

@anakinj What's the time frame for 3.0? Could we release a new minor version with my changes just for the time being? I can then help adapt the changes for the new version going forward. I just need this support sooner if possible, otherwise I will have to find another library to use.

If I could tweak my changes in a way that fits the new API in 3.0 going forward, I am happy to do so. Let me know. Thanks.

[anakinj]

Currently there is not really a schedule, tinkering on it when there is extra time. I understand that there is a need but at the same time a bit hesitant bloating the current codebase even more.

Is it a possibility to use your feature via a fork until it's properly integrated into a version?

[anakinj]

I'm going to abandon the Version 3.0 API changes. The changes were adding way too much performance overhead. Focus will now to do gradual improvements based on inspiration of the work done in the past.