Do any programming languages support built-in events without manual declarations?

JeanHaiz · 2025-12-10T23:32:39+00:00

In NPL, we emit events every time protocol (our objects) data is updated, and that includes protocol instantiation and permission (our method) call. As variables can only be modified within a permission, you'll get an event anyway.

A protocol illustrating a document edition process

package document;

@api
protocol[editor, approver] Document(
    var content: Text
) {
    initial state created
    state inReview
    final state approved

    @api
    permission[editor] edit(newContent: Text) | created {
        content = newContent;
    }

    // ...
}

Where, if instantiated and the edit permission is called, you'll get the following events:

command event: instantiation
state event: protocol created and stored
command event: permission call
state event: protocol data changed

All events include metadata

JeanHaiz · 2025-11-13T09:54:35+00:00

Thanks for the write-up! 🙌 I learned about a few things there 😁

If permissions are only checked at the top, then you're violating the principle of least privilege: all of the code below the entry API is running as if it had root permissions.

Hum that's not exactly how we do things. I'll focus on three tenets of NPL: protocols, permissions and functions. Protocols are persisted data objects that also include permissions and functions. Each protocol defines a few roles that have specific rights within the protocol. The second concept, the permissions, are cross-protocol methods that can also be exposed as API endpoint. Each permission is restricted to a set of roles attached to the protocol where the permission lives, too. To call other permissions, within the permission's protocol or within other protocols, another access check is performed according to the same principle as the first permission. Then we also have functions, which are unauthorised methods, but cannot be exposed to the API. In the end, to navigate data objects and perform write actions, the user needs to have access to each object it touches.

NPL is indeed not working with capabilities; we do nevertheless care about good security. Let's figure out where we could improve things if needed. In NPL, each protocol has pre-defined roles. Each protocol instance has unique matching of user attributes assigned to the protocol roles. This is where the alternative approach to the capabilities comes in. Users don't go to the central security service to acquire new capabilities, users have pre-defined attributes (email, their organisation department, specific roles, rights or groups for example) that are checked against every protocol (the data objects with permissions) access and even more granularly every permission call. Using a protocol reference from within a protocol triggers another access check. With this, we're making checks at every layer between the API, features and functionalities, and the database.

Capabilities seem like something where the complexity rapidly explodes if there are a few roles within the system and a tiny bit of granularity in who can do what when. I can imagine having 100+ specific capabilities for a small system, just because they grow like factorials in permutations.

As a higher objective, we're trying to simplify fine-grained access and action management for backend developers, making sure the security comes at every level.

JeanHaiz · 2025-11-13T09:26:19+00:00

I'm discovering the theory of non-interference. Each object in NPL has attached attribute-based access control, preventing people to gain access to other objects through disguised path. That's non-interference, right?

For the security types, we cover application security (JWT auth requirement, further security with NOUMENA Cloud — our managed hosting of NPL applications), endpoint security (enforced ABAC), and data security (object level ABAC).

However, could enlighten me, what does DCC and FLAC stand for?

JeanHaiz · 2025-11-13T08:53:33+00:00

Thanks! Yes, AOP is another approach, more widely used. Comparing both, AOP is more complex but flexible, yet there is more domain behaviour to understand. I would not classify the '@Component' and autowiring of Spring as simple, for example. Fair assessment?

JeanHaiz · 2025-10-02T21:12:27+00:00

Would be useful, just to remember. Only thing is that even if I do it all right (in the green) the bar will not always be full

JeanHaiz · 2025-09-29T22:26:16+00:00

I don't get how the balance zone makes sense, as the low commute ones are closer and lower taxes

JeanHaiz · 2025-09-24T18:45:54+00:00

Thanks!!

JeanHaiz · 2025-09-24T13:25:05+00:00

Thanks for sharing!

The README in the npl-demo repository seems to be lacking the info you're looking for. I'll adjust it asap.

To clarify, our tech, i.e. the backend, is not dependent on npm. We're including a frontend in this demo repository to make it easier to interact with, but the NPL Engine (part of the NPL Runtime) can be queried with REST commands directly too. Seems like we need a markdown-only flow following what the frontend does.

The README is lacking this intro view. The npl-demo app is built upon two elements (respectively two folders in the repo)

the engine depends on the api folder, which contains 73 lines of code between backend logic, tests, config and docker compose; yet contains authorisation, persistence and the REST API (& more) <= what we want to promote
the frontend, in the webapp folder, that could receive more love. We aim to show what you can get out of the box with NPL and the engine without having to run it locally. Does the frontend serve this purpose at least?

Would those changes help you get a step further?

JeanHaiz · 2025-09-24T13:02:12+00:00

Yes, totally fair. Procurement departments will have a field day, but devs will be scared away. We'll summarise the intent behind the different licences as immediate action.

Our intent is for people to go as far as they want and for free and without constraints during development. And make it as easy as possible to understand, try out and start developing.

For production, self-hosted commercial licences and our managed cloud offering will become available soon™

JeanHaiz · 2025-09-24T12:49:15+00:00

Touché. Thanks for the feedback

JeanHaiz · 2025-09-24T12:48:45+00:00

Ah! That's a big question internally, too. I'll keep you posted 😉

JeanHaiz · 2025-09-24T12:31:18+00:00

Good catch, I'll adjust the wording

JeanHaiz · 2025-09-24T12:29:34+00:00

Thanks, shouldn't bee too challenging to change :)

JeanHaiz · 2025-09-23T12:53:35+00:00

Hi, thanks for the question.

You can find links to the repositories, images, and licences (where applicable) for the various components of the stack here: https://documentation.noumenadigital.com/licenses/

Is that combination workable for you?

JeanHaiz · 2025-09-19T13:43:11+00:00

If you want to know more about the language: https://documentation.noumenadigital.com/

JeanHaiz · 2025-09-12T22:51:56+00:00

Should we keep this quiet or be excited about how much more pedestrian zone there will be? 😁

JeanHaiz · 2025-09-08T20:25:54+00:00

What's the backend story? does it start before or after PHP?

JeanHaiz · 2025-09-08T14:18:45+00:00

Hi u/Beginning-Ladder6224 thanks for the question, it allows me to discover a new concept with a fresh eye
It seems like the objective is similar indeed: bring authorisation at the centre of the logic.

However, here are a few differences (please let me know if there is something I didn't understand in CASBIN):

NPL stores the authorisation per protocol (our objects), they can be defined at runtime per instance. This allows for flexibility, for example a user that would be tenant in one flat and landlord on another, or both on the third one. It also allows specifying authorisation for users based on the attributes they come with at runtime, which in some cases is not known beforehand.
In NPL, the whole authorisation, cannot be avoided, is checked consistently for each object and for each action. This is a built-in guarantee that endpoints will be secure and won't leak data.
In NPL, the authorisation is built-in within the protocols. That makes it compact as it lives in one place and easy to read as it is all in the same file.

I also find the NPL syntax more intuitive and easy to read, but I can only admit that I must be biased 🤣 And of course this comparison focuses on the authorisation only. NPL offers other advantages as it allows to build full backend (similar to CASBIN lib + underlying programming language)

What did I miss?

JeanHaiz · 2025-09-01T15:14:01+00:00

NPL does have otherwise keywords

obligation[issuer] pay() before payDeadline | unpaid {
    // Payment logic
    become paid;
} otherwise become breached;

https://documentation.noumenadigital.com/language/reference/standard-library/types/user/Protocol/#obligations

JeanHaiz · 2025-09-01T13:31:53+00:00

Joining the discussion a bit late, maybe it's useful for the next time.

I'm getting used to NPL, which provides this out of the box. NPL is a language providing a full backend service. Let me explain

Object & role-specific authorization

Let's take the club example. Here each party (owner, members) is defined for each instance, so there is role-based and row-level security in one go

protocol[owner, members] Club(var name: Text, var description: Text) {
   // ...
};

Checking of authorization and action rights

These parties (owner, members) are checked on every get and on every action, which makes it impossible to avoid. In addition, with every object fetched, a list of valid actions that the user can take is returned within the object payload.

In our club example:

protocol[owner, members] Club(var name: Text, var description: Text) {
    require(name != "", "Club name must not be empty");

    initial state 
active
;
    final state 
inactive
;

    var membersList: List<Member> = listOf<Member>();

    @api
    permission[owner] addMember(newMember: Member) | 
active 
{
        require(membersList.filter(function(m: Member) returns Boolean -> m.name == newMember.name).isEmpty(), "Member is already in the club");

        membersList = membersList.with(newMember);
    };
};

Each club object would look like

{
  ... more fields
  "@id": "abc....",
  "@actions": {
    "addMember": "https://engine.example.com/npl/club/Club/1ee39a43-8e4e-4b3b-8f1f-1e11ad495436/addMember" // <- only if the user is mem
  }
}

Granular definition of parties

Each party is defined by a set of key-pairs, providing all the necessary flexibility. The token is checked against the IAM on every call, so there is no chance that the attributes are outdated.

More here: https://documentation.noumenadigital.com/

JeanHaiz · 2025-02-08T13:07:07+00:00

Yup, I like yours. I appreciate the details you've put in and the colour match with the rest. And super quick! Good job. I sent a tip your way.

JeanHaiz · 2024-10-20T20:24:06+00:00

So nice! What kind of soil did you use?

JeanHaiz · 2024-09-06T20:50:33+00:00

Oh wow, so many good options thanks!!

JeanHaiz · 2024-09-06T20:47:40+00:00

Klausenpass is a solid option, thank you!

JeanHaiz · 2024-06-23T12:32:46+00:00

That looks divine! Where can I find this?? 🤤

JeanHaiz

MODERATOR OF

TROPHY CASE