In Network Compute and the end-to-end design principle(s)

 There's some confusion about this - the e2e principle was originally about OS layering and the idea of parsimony. It was transfered by folks at MIT to the functionality of communications protocol layers, hence we get the "thin waist" of the TCP/IP stack, IP, and the plethora of link and physical layer technologies, and the diversification of transport (end-to-end) protocols and applications and shims above, particularly end-to-end encryption (TLS or QUIC built in etc). All good.

A. Now add in-network compute and two things happen - 

1/ Compute is the end point of some data and normally would therefore need keys to decrypt comms. 

2/ Compute is another resource along a path so we now have recursive layering - the common use cases assumes there are "final" end points, but we need all the usual services we expect "end-to-end" for those AND for the in-network compute middle-end point - i.e. not just crypto, but also, integrity, reliability, flow and congestion control,  and so on, as these intermediaries are talking over IP, which doesn't do that, because thin-waist etc

3/ So we just have recursive e2e - no problem there. Just another tunnel/vps etc

B. Ah, but now lets do something less old-fashioned - what if

a) the in-network compute is able to work on encrypted data (e.g. is homomorphic crypto function) or is a secure multipaty computation and

b) the in-network compute is redundant (or loss tolerant) too.

Then we don't need it to be a principle in the e2e2e crypto. Nor do we need integrity or reliability checks.

However, in both A and B, we do still need flow/congestion control, and, what is more, that resource management is now no longer merely based on queues (ECN etc), but is based on computational (and possibly associated storage) resource management too. And we need to signal that across the e2e2e protocol, not something TCP or QUIC do, but perhaps could be added in to MASQUES for example....

just a thought.

from centralised to decentralised - what's in the journey

 we're seeing a shift from central (meta/twittter) to decentralised (mastodon/matrix) 

aside from ownership, control, use of data, what's the difference?

for me, the difference is about defaults and assumptions made in naive, or initial (alpha) implementations

In a centralised system, the operator has centralised cost, and needs to offset those (cloud/data center charges or operational overheads) by monetizing your data (adverts) or your interest (subscription)

in a peer-to-peer (the older name for dencentralised) system, these costs are a marginal increase in operations of systems run by the user. The amount more processing/networking/storage incurred compared to having your client talk to the cloud is little (possibly even a decrease, since your peer group may be nearer).

so you don't need to run a business to pay for the infrastructure, because that is a given.

so then in the central system, it is very easy to data mine/run AI on all the users. It would take a lot of work to provide fine grain access control and cryptographic protection of privacy for all users - Privacy Enhancing technologies to allow such things would involve Homomorphic Encryption, for example, which would be a large increase in operational overheads. And would need to be implemented and deployed

so then in the decentralised system, users share only the data they wish, only with the other users they wish to share with. It would take a lot of work to design a decentralised data mining system to build models of all the users (e.g. some large scale federated learning, perhaps also using multiparty secure computation or the like).

so if you start decentralised, you are likely to stay that way for resource reasons, and you are likely to stay private.

so if you start centralised, you are likely to stay that way for capitalist reasons, and likely to stay privacy invasive

of course, the decentralised systems are, trivially, more sustainable. as well.

I know who I'd back, in the long run.

wired for sound - review of in-the-round jazz at cockpit theater, 31.10.2022

Went to the October 31st edition of Jazz in the Round at the excellent Cockpit theater in Maida Vale - this session offered

Mackwood - a trio (did not get guitar/bass players names, but very very fine chord/ensemble work with the lead drummer) - some of other work here but apparently, this line up has a recording out very soon - watch that space - a bit holdsworth, but restrained and more melodic, and clever rhythms

Million square - a sax/electronica duo - very fine - more here of theirs - some neat hybrid analog/digital loop/sample tricks - all to good purpose!

 Loz Speyer's Time Zone - i couldn't stay for the whole set, but got up to Mood Swings, which was great - they have a really crazily good cuba feel - loose but very tight under the hood with fun melodies and constantly shifting arrangements.

Loz also told two stories about songs he'd written travelling to&fro between UK and Cuba -

one brief explanation of a song  "lo que no te mata: (the thing that doesn't kill you), which, apparently in Cuba, ends with "te engorda (makes you fat, as opposed to the english "makes you stronger")....:)

the second was about the origin of the Mood Swings song, which was that he was staying with a friend in Cuba who'd been laid off from working on repairing lifts- apparently, they'd run out of older other lifts to cannibalise for parts - most older stuff in Cuba is made out of pieces scavanged from french, latin american, US and (of course) russian parts to keep it going - he explained that that was how he wrote the song...

Weird anecdote of my own - in the 1970s, my mother, who was a concert pianist but also taught at the Royal Academy of Music ran an improv event based on the story/themes Tempest at the Cockpit - i came along to help with sound and tech in general - i recall messing with a sax player who had the first copycat (wem?) loop box i'd ever played with - an echo through time and space! no sprites/troubled spirits of the air visited however, just light rain.