Checking on Maintenance / Would you be interested in contributing to a spec?

[TotalTechGeek]

Hey @diegoholiveira, 👋🏻

And I might as well ping @beeme1mr (this post is the reason I saw the other issue 😂)

I'm currently trying to reach out to other JSON Logic project maintainers to try to get a community dialog started around building a more rigorous spec for JSON Logic and develop compatibility tables / a decent test suite.

As y'all might be aware, there are inconsistencies between different implementations of JSON Logic, and various behaviors that are difficult / impossible to support out of the box.

I'm going to copy parts of the message that I've sent to other folks,

---

I wanted to reach out and inquire:

• Is this project still something you're interested in maintaining? (Based on the other issue, it seemed like you were still interested in maintaining the project, but would like support from community & PRs to be filed)
• Would you be interested in working with a community of other JSON Logic maintainers to help develop a more rigorous specification, so we can resolve compatibility issues between implementations?

To be clear... this would be a community effort -- I've been trying to get a hold of Jeremy for a few years now, but I haven't had much success chasing him down 😅 . If he takes notice, I'd love to have him involved.

My goal though is to get a dialog going between different maintainers and build a spec + compat table so JSON Logic can be more beneficial to folks.

There are some quirks with different implementations, some ambiguities in the "spec" we have now, and some impossible behaviors that I think would be helpful for the community to address.

Examples of issues I think need discussed & spec'd:

• Data: How do you access { '': 1 }?
• Data: How do you access { 'hello.world': 1 }
• Truthiness: straightforward, but a compat table might be helpful
• How do you handle { "!": [0] } vs { "!": 0 } -- this one is more straightforward; but a common compat issue.
• How do you handle { "!": { "var": "data" } } where data resolves to [0], is it treated like [[0]] or [0]?
• How do you access context in iterators? {filter: [{var: 'arr'}, {'===': [{var: 'item'}, {var: '../../choice'}]}]}; explanation: In most implementations, you're unable to access above context in your iterator, so you can't use data to add numbers together, or filter things out.
• .length, should var in JSON Logic have a dedicated handle to allow a user to fetch .length if the property does not exist on the object naturally? Most implementations do not handle this. This makes logic incompatible in between interpreters; so should .length be treated as a special path, or be given a reserved operator 😉

My hope is to get folks discussing backwards compatible approaches, and help provide resources to projects to help iron out implementation differences.

So:

• Would you be interested in participating?
• If not interested in the spec, would you be interested in receiving PRs based on community input?

---

@beeme1mr I'd also be happy to have your involvement too. You're probably one of the largest users of multi-platform JSON Logic, and you're the type of user a more rigorous spec & test suite would likely benefit.

My long term goals are to:

• Develop a Spec
• Identify common issues with the spec and address them
• Provide project maintainers with resources to help smooth over implementation differences.
• Once compatibility is solid; it might be nice to spec out common operators & release common extensions.

[diegoholiveira]

Hey @TotalTechGeek , that's an awesome move. About two questions made:

Is this project still something you're interested in maintaining? (Based on the other issue, it seemed like you were still interested in maintaining the project, but would like support from community & PRs to be filed)

I'm still maintaining this project and I would love to implement the future spec (also, I'm trying to find an opportunity to use generics on some parts of the code, so both things could be made together).

Would you be interested in working with a community of other JSON Logic maintainers to help develop a more rigorous specification, so we can resolve compatibility issues between implementations?

Unfortunately I can't. I don't have any spare time at this moment to be part of this.

I've been trying to get a hold of Jeremy for a few years now, but I haven't had much success chasing him down

I also tried to contact him to better understand how can I help to keep this project alive. Last time that I saw some online activity was on this PR: jwadhams/json-logic#10

I would be great to have @jwadhams on this initiative. Or at least create an organization and let you be an administrator.

[jwadhams]

Yeah I'd be game to meet with some other maintainers and try to figure out the future of the project. This isn't core to my 9-to-5 job anymore, so it's difficult to prioritize anything other than security fixes.

[TotalTechGeek]

Oh, hey @jwadhams!

You have no idea how stoked I am to have you involved! 😂

Is there a place that's best to contact you without harassing you?
Email? GitHub? Linkedin? Bluesky?

Your creation has enabled some pretty cool capabilities for folks. Heck, the EU even used JSON Logic to try to define rules for Digital Vaccine Cards.

JSON Logic fills a very useful (and surprisingly common) niche (I love using it as an AST), and my hope is that a spec and community effort might help folks.

[beeme1mr]

Hey, @TotalTechGeek, I'd be happy to help out. We use JSON Logic as the basis for a feature flag evaluation engine, and it has proven quite flexible and powerful. Addressing some inconsistencies and improving runtime performance would be amazing.

[toddbaert]

I'd also be willing to help. I'm from OpenFeature as well (in addition to @beeme1mr ) and we use JsonLogic heavily in multiple languages.

My intuition is that creating a JSONLogic github org might be a good way to go - and using that as a place to discuss the specification of the points you mention, as well as perhaps eventually a place to house implementations. Personally I think that enterprises are more willing to use OSS projects that have some semblance of governance and exist under a github org rather than people's personal spaces - but that's just my experience.

Another, perhaps more ambitious move, might be to apply for CNCF membership. The CNCF could provide a lot of tools and bring eyes onto the project as well. Of course the project would become the property of the CNCF, so I think we'd probably need an OK from @jwadhams and any other original authors in order to consider that - but it might be a good way from them to divest while making sure the project survives and is stewarded appropriately going forward.

Your creation has enabled some pretty cool capabilities for folks. Heck, the EU even used JSON Logic to try to define rules for Digital Vaccine Cards.

JSON Logic fills a very useful (and surprisingly common) niche (I love using it as an AST), and my hope is that a spec and community effort might help folks.

Wow, what a use-case!

Personally, the thing I find great about JSON logic is that it's (of course) JSON. This means you can validate and parse it anywhere you can validate and parse JSON, making it ideal for encoding rulesets into Kubernetes resources, which otherwise would be just blobs of embedded CEL or some other expression language. This is one of the ways we use it in OpenFeature and another reason why the CNCF might be relevant.

[toddbaert]

For the curious, here's an easy-to-understand example of how we use JSON logic in OpenFeature (notice the realtime editor support and validation): https://flagd.dev/playground/?scenario-name=Enable+for+a+specific+email+domain

This is the same sort of thing you can embed in K8s custom resources.

[TotalTechGeek]

Hey folks, I'm going to start inviting maintainers / stakeholders who've expressed interest to a GitHub organization, and get some repositories / projects going so we can consolidate comms on this initiative.

We'll work on the org permissions with time, all members should have write access.

[codetiger]

Thanks for the wonderful initiative @TotalTechGeek
Ive created a Rust implementation for the JSONLogic spec here: https://github.com/Open-Payments/datalogic-rs

playground: https://portal.openpayments.tech/rulelogic

[diegoholiveira]

Hey folks, I'm going to start inviting maintainers / stakeholders who've expressed interest to a GitHub organization, and get some repositories / projects going so we can consolidate comms on this initiative.

We'll work on the org permissions with time, all members should have write access.

Great. Thanks for that!

I'll try to understand how to move my repo to this new org.

[TotalTechGeek]

@diegoholiveira No need to move anything unless you actively want to!

I mainly just want to get a unified place for discussions and spec/compat/proposals going! 😄

I don't think it'd be a bad thing if folks wanted to put their projects under the org umbrella! I'd be happy to move mine as well (once we get perms a bit better established).

But there's no expectation / requirement for that, heh.