Pinecone is a very generic overlay - while it’s hooked up in Matrix as a way of connecting nodes as a bearer for uTP requests, you could equally well layer IPv6 over it similarly to how Yggdrasil works. CapTP is at a much higher level - aiui it’s effectively distributed RPC with a capability security model, promise pipelining and distributed GC. I see it as more similar to the higher layers of Matrix, which give you decentralised access controls and eventually consistent data replication (albeit no RPC). So: yes, you could absolutely put a CapTP implementation over Pinecone.
Maybe? It depends on the ultimate goal. The typical goal of CapTP implementations is to deliver messages from one machine to another, but that is also what Pinecone claims to do; therefore, it might not be necessary to build CapTP on top of Pinecone.
Hmm, you might be right.
Perhaps, I did have the right ‘categorization’ of capabilities of these systems.
I was looking at CapTP as sort of a modern day CORBA, with the clever methodology to manage trusts across applications representing user/technical account identities (CORBA did not do that).
While Pinecone is a system that manages trust and connectivity at the level of networked devices (nodes) – which in my, perhaps, superficial understanding, CapTP did not do.
At the end of the day one need to trust network nodes, the pipes, the applications, and the user identities.
When a system, such as an OS or a website, is presented with a request for a service it provides, it needs to decide if it should actually do what the requestor is asking for. The way it decides is what we’re talking about when we talk about access control. If you’re like most people, the first thing you’re likely to think of is to ask the requestor “who are you?” The fundamental insight of the capabilities paradigm is to recognize that this question is the first step on the road to perdition.
We do not need to trust nodes, applications, nor identities. Capability-oriented computing arises out of an understanding that we do not need to trust remote machines in order to achieve useful computation with them.
Could this be used to implement (seat underneath) the CapTP (Capability Transport Protocol )?
Pinecone is a very generic overlay - while it’s hooked up in Matrix as a way of connecting nodes as a bearer for uTP requests, you could equally well layer IPv6 over it similarly to how Yggdrasil works. CapTP is at a much higher level - aiui it’s effectively distributed RPC with a capability security model, promise pipelining and distributed GC. I see it as more similar to the higher layers of Matrix, which give you decentralised access controls and eventually consistent data replication (albeit no RPC). So: yes, you could absolutely put a CapTP implementation over Pinecone.
If the network is generic enough, I don’t see why not
Maybe? It depends on the ultimate goal. The typical goal of CapTP implementations is to deliver messages from one machine to another, but that is also what Pinecone claims to do; therefore, it might not be necessary to build CapTP on top of Pinecone.
Hmm, you might be right. Perhaps, I did have the right ‘categorization’ of capabilities of these systems.
I was looking at CapTP as sort of a modern day CORBA, with the clever methodology to manage trusts across applications representing user/technical account identities (CORBA did not do that).
While Pinecone is a system that manages trust and connectivity at the level of networked devices (nodes) – which in my, perhaps, superficial understanding, CapTP did not do.
At the end of the day one need to trust network nodes, the pipes, the applications, and the user identities.
From an introduction to capabilities:
We do not need to trust nodes, applications, nor identities. Capability-oriented computing arises out of an understanding that we do not need to trust remote machines in order to achieve useful computation with them.
Routing over self organizing BLE meshes could be very cool for events like ToorCamp with spotty cell and wifi signals