#BaseParadigm is a conceptual data browser based on the #MVVM pattern. In the BaseParadigm, views are rarely new. Rather, common View-Models conform to known patterns, and therefore have common Views. The Model layer is diverse, and moves quickly. A post to the #SocialWeb might appear in a number of different Models, and would trigger View-Model visibility through a number of methods. Those who care to View these posts would receive the VM populated with the latest data from appropos sources.

So basically permissions systems can be built with the fundamental primitive of API keys (for remote processes known to be reachable) and/or public keys for cryptographic security models.

I don't see a need for access control lists beyond interfacing with other software systems according to their model. Software in the #BaseParadigm usually would have sub-second runtimes, beginning on-demand and exiting fast so that the Human may act.

#Capabilities? If the above doesn't qualify…

Two more concepts central to #BaseParadigm, to wrap up that cursory thread.
#Permissions: BaseParadigm gives none.
The interface to BaseParadigm regards composition of data through declarative APIs. Data structures of all kinds may be manipulated with functions of all kinds, explicitly, via human touch. This does not have to look technical, but BP functions do not access the filesystem, network, or anything. They have in-memory input and output to the UI. No permissions.

I'm guessing I lost a large part of my small audience not mentioning conditional pub/sub structures, DHTs, low latency streams, and granular queries.
I would begin by referencing #localFirst and saying, start with the filesystem. With some basic shared state an app could then initialize other protocols on-demand.
But within the scope of #BaseParadigm would be a distributed index. I do think indices of various kinds are fundamental to navigation of unbounded spaces like the #web.

I forgot that almost 15 years ago I was envisioning #BaseParadigm as a p2p app platform based on filesystem synchronization.
So, you could use a shared folder between users on the same device or server, or a networked or synced folder (s), or sporadic rsyncs.
I'm just going to outline some of those thoughts. (1 of ?)