On the Far Side of REST
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 287 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 2.0 Belgien: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/57067 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSDEM 2022267 / 287
2
4
6
8
12
17
21
23
31
35
37
41
44
45
46
47
50
62
65
66
67
68
71
73
81
84
85
86
90
92
94
100
102
105
111
114
115
116
117
118
121
122
124
127
131
133
135
137
139
140
141
142
145
149
150
156
164
165
167
169
170
171
172
174
176
178
180
183
184
189
190
192
194
198
205
206
207
208
210
218
220
224
225
229
230
232
235
236
238
239
240
242
243
244
245
246
249
250
253
260
262
264
267
273
274
277
282
283
287
00:00
REST <Informatik>Projektive EbeneBitRelativitätstheorieMomentenproblemDiagrammBesprechung/Interview
00:49
InternetworkingProtokoll <Datenverarbeitungssystem>MAPCoxeter-GruppeOffice-PaketBenutzerfreundlichkeitAutonomic ComputingZeitzoneMereologieQuick-SortAutonomic ComputingMAPParallele SchnittstelleProjektive EbeneGenerator <Informatik>AdressraumProtokoll <Datenverarbeitungssystem>HilfesystemStreaming <Kommunikationstechnik>Content <Internet>FokalpunktMultiplikationsoperatorInternetworkingRechenschieberComputeranimation
03:23
Hill-DifferentialgleichungEinfügungsdämpfungInternetworkingChiffrierungDigitalsignalOvalContent <Internet>Cookie <Internet>DatenmissbrauchSchnittmengeSoftwareentwicklerRechenschieberQuick-SortDigitalisierungRechter WinkelMereologieTermGrundraumPunktDeklarative ProgrammierspracheBitMultifunktionInternetworkingGesetz <Physik>ChiffrierungSichtenkonzeptInterpretiererSoftwareMathematikStochastische AbhängigkeitStrömungsrichtungProjektive EbeneAuswahlaxiomDatenmissbrauchAbstimmung <Frequenz>Open SourceFreewareKoalitionParametersystemComputeranimation
07:52
RechnernetzSoftwareSkalierbarkeitSoftwarearchitekturREST <Informatik>Overhead <Kommunikationstechnik>VollständigkeitRechenschieberCodePartielle DifferentiationContent <Internet>ServerPhysikalisches SystemImplementierungFunktion <Mathematik>ComputersicherheitTLSDatenmissbrauchZeitabhängigkeitExogene VariableStrukturierte DatenNeue MedienQuick-SortProjektive EbeneREST <Informatik>Elektronische PublikationComputersicherheitTLSAdressraumKomponente <Software>PunktSoftwarearchitekturDatenmissbrauchImplementierungKategorie <Mathematik>NebenbedingungVersionsverwaltungChiffrierungSoundverarbeitungMathematikExistenzsatzParametersystemAbstraktionsebeneGrenzschichtablösungStandardabweichungBitIterationProtokoll <Datenverarbeitungssystem>RechenschieberTermMapping <Computergraphik>ProgrammMereologieDatenfeldUmsetzung <Informatik>CASE <Informatik>SichtenkonzeptEvoluteInterface <Schaltung>Proxy ServerSkalierbarkeitDiagrammSoftwareÄhnlichkeitsgeometrieAuswahlaxiomComputeranimation
14:30
Neue MedienExogene VariableStrukturierte DatenREST <Informatik>ServerAuthentifikationSelbstrepräsentationCodeGenerizitätImplementierungClientProtokoll <Datenverarbeitungssystem>KontrollstrukturWärmeübergangGrenzschichtablösungWeb ServicesSynchronisierungCodeQuick-SortPunktwolkeVirtuelle MaschineProgrammierparadigmaZentralisatorVerschiebungsoperatorNeuroinformatikCASE <Informatik>BenutzerbeteiligungREST <Informatik>ClientAutorisierungServerDifferenteKartesische KoordinatenProtokoll <Datenverarbeitungssystem>FitnessfunktionMomentenproblemEndliche ModelltheorieExogene VariableSoftwarearchitekturBitLokales NetzMereologieFunktionalNatürliche ZahlMultiplikationsoperatorRichtungSelbstrepräsentationTelekommunikationImplementierungDatenstrukturNeue MedienInformationsspeicherungRPCKategorie <Mathematik>PunktElektronische PublikationAuthentifikationDatenmodellVideokonferenzGeradeTotal <Mathematik>SchnittmengeComputeranimation
20:43
DistributionenraumRechnernetzAuthentifikationEchtzeitsystemServerVerschlingungDatenübertragungDateiformatGenerizitätMathematische LogikDatenmissbrauchChiffrierungClientMAPNebenbedingungREST <Informatik>KontrollstrukturPhysikalisches SystemSchlüsselverwaltungEndliche ModelltheorieKategorie <Mathematik>NebenbedingungMehrrechnersystemBitQuick-SortAuthentifikationSoftwareWorkstation <Musikinstrument>MomentenproblemPhysikalisches SystemTelekommunikationServerMAPFokalpunktDatenmissbrauchCodeEchtzeitsystemPunktWeb ServicesGamecontrollerEreignisdatenanalyseTranslation <Mathematik>ProgrammClientProzess <Informatik>RechenwerkFacebookSpeicherabzugCachingCASE <Informatik>REST <Informatik>IdentitätsverwaltungGüte der AnpassungSoundverarbeitungProtokoll <Datenverarbeitungssystem>AutorisierungSichtenkonzeptInterface <Schaltung>DistributionenraumZeiger <Informatik>Mechanismus-Design-TheorieObjekt <Kategorie>FunktionalArithmetisches MittelEinsÄußere Algebra eines ModulsAbstimmung <Frequenz>DefaultStellenringURLBildschirmmaskeComputeranimation
27:18
URLNebenbedingungCachingPhysikalisches SystemIndexberechnungDistributionenraumDateiformatGenerizitätStochastische AbhängigkeitCodeTransformation <Mathematik>UmwandlungsenthalpieDatenmissbrauchMaßerweiterungBrowserQuick-SortBenutzerbeteiligungTypentheorieQuaderATMRechter WinkelDifferenteMixed RealityMereologiePunktSpeicherabzugTransformation <Mathematik>Kartesische KoordinatenRechenzentrumEchtzeitsystemDistributionenraumWeb-ApplikationURLBenutzerprofilMAPContent <Internet>Physikalisches SystemProxy ServerHilfesystemKomponente <Software>InformationDateiformatSelbstrepräsentationAuthentifikationCodeGrenzschichtablösungBitSerielle SchnittstelleVersionsverwaltungServerCachingFramework <Informatik>BrowserMechanismus-Design-TheorieStandardabweichungWeb ServicesKategorie <Mathematik>BildschirmmaskeCASE <Informatik>ClientREST <Informatik>ProgrammbibliothekNeue MedienResultanteIdentitätsverwaltungNebenbedingungSchreiben <Datenverarbeitung>SprachsyntheseComputeranimation
33:34
REST <Informatik>EchtzeitsystemDedekind-SchnittÄhnlichkeitsgeometrieNetzwerkschichtRoutingDarstellungsschichtProtokoll <Datenverarbeitungssystem>KugelkappeToken-RingIdeal <Mathematik>SenderStochastische AbhängigkeitGruppenoperationIdentitätsverwaltungProzess <Informatik>ProgrammierungInterprozesskommunikationSoftwarePhysikalisches SystemDatenmissbrauchDateiformatKompakter RaumAuthentifikationAdressraumTLSMaßerweiterungWort <Informatik>TypentheorieFeasibility-StudieProjektive EbeneChiffrierungProtokoll <Datenverarbeitungssystem>Quick-SortTelekommunikationSoftwareMultiplikationsoperatorBitDifferenteKontrollstrukturPunktCoxeter-GruppeAbstraktionsebeneInterface <Schaltung>Einfach zusammenhängender RaumVirtuelle MaschineSichtenkonzeptPhysikalischer EffektSprachsyntheseFormale SemantikNichtlinearer OperatorAuthentifikationTransmissionskoeffizientAutorisierungMereologieMehrrechnersystemOrdnung <Mathematik>Lesen <Datenverarbeitung>Token-RingContent <Internet>Formale SpracheRechter WinkelServerStellenringWahlfreier ZugriffPhysikalische SchichtObjekt <Kategorie>InterprozesskommunikationEinsSchaltnetzZentralisatorProgrammierumgebungRelativitätstheorieBenutzerbeteiligungSerielle SchnittstelleDivergente ReiheArithmetische FolgeKomponente <Software>Digitales ZertifikatFolge <Mathematik>ÄhnlichkeitsgeometrieATMMechanismus-Design-TheorieInternetworkingComputeranimation
43:16
Protokoll <Datenverarbeitungssystem>DarstellungsschichtTypentheorieFeasibility-StudieGleichmäßige KonvergenzWort <Informatik>Interface <Schaltung>ImplementierungBeschreibungskomplexitätVarietät <Mathematik>SoftwareentwicklerServerVersionsverwaltungKontrollstrukturDateiformatRandwertDatenstromCachingRechnernetzObjekt <Kategorie>Operations ResearchContent <Internet>Feinstruktur <Mengenlehre>Transformation <Mathematik>Framework <Informatik>Overlay-NetzHash-Algorithmusp-BlockGüte der AnpassungAutorisierungFehlermeldungForcingQuick-SortPunktCachingSystemaufrufUniformer RaumObjekt <Kategorie>ClientInterface <Schaltung>Content <Internet>REST <Informatik>Nichtlinearer OperatorFramework <Informatik>AlgorithmusInternetworkingProjektive EbeneImplementierungWeb SiteStochastische AbhängigkeitCASE <Informatik>RohdatenCoxeter-GruppeKartesische KoordinatenTypentheorieDifferentePhysikalische SchichtServerProxy ServerGamecontrollerVarietät <Mathematik>Protokoll <Datenverarbeitungssystem>HilfesystemPareto-VerteilungMultiplikationsoperatorTransformation <Mathematik>Komplex <Algebra>VersionsverwaltungMultiplikationMathematikStellenringRandwertInformationMAPGebäude <Mathematik>Divergente ReiheLeistung <Physik>Elektronische PublikationStrömungsrichtungRechter WinkelURLTabelleBitAuflösung <Mathematik>AdditionMereologieTermResultanteE-MailSenderComputeranimation
52:52
Framework <Informatik>Transformation <Mathematik>Hash-AlgorithmusOverlay-NetzFeasibility-StudieServerLokales MinimumChatten <Kommunikation>Schreiben <Datenverarbeitung>SoftwareChatten <Kommunikation>PunktOrdnung <Mathematik>MereologieBridge <Kommunikationstechnik>TeilbarkeitProjektive EbeneMatrizenrechnungProgrammfehlerComputeranimation
54:49
BenutzeroberflächeVideokonferenzBesprechung/InterviewComputeranimation
55:40
Projektive EbeneRechter WinkelBesprechung/Interview
56:36
Chatten <Kommunikation>EinsMehrrechnersystemProjektive EbeneREST <Informatik>MereologieQuick-SortPunktGüte der AnpassungLesen <Datenverarbeitung>Minkowski-MetrikProxy ServerBesprechung/Interview
58:32
Quick-SortMatrizenrechnungBesprechung/InterviewComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:09
Hi, and welcome to this talk on FOSTER on the far side of rest. This is a talk that somewhat relates to a talk I gave last year at FOSTER on the Interpeer
00:21
project. But in this year's talk, I want to focus specifically on this R&D topic, I'll get into this in a moment. But of course there is relation to the rest of the overall project and of course I will have to mention this once in a while. So this is really the question of what should we do with rest and what can we see beyond
00:45
that. And the project, the Interpeer project as a whole, or of me as a person, both, a bit of a mixture, receives money, funding from the Internet Society Foundation. That's new, it's a grant that started last September.
01:05
And that sort of covers most of the topic of today's talk. But also from the Enelnet Foundation, and Enelnet here is managing the NGI Zero Fund, which is part of the Next Generation Internet Initiative, which again is a project of the
01:22
European Commission. So really these three entities to me are more or less one and the same, but it's sort of important to understand how this is structured. The funding topics within the Interpeer project are sort of twofold. On the NGI Zero grant, I'm performing R&D into transport and other lower level
01:46
protocols, networking protocols, with a strong focus on streaming. And for the ISOC Foundation, I'm working more on the higher level protocols that sort of assume these lower level protocols already exist. Not the case, the work is going on in parallel.
02:02
And in that way, I can take learnings from one effort into the other and vice versa. And so that actually is beneficial, but it is sort of topicly separated a little bit. Quick organizational thing, one is that I'm starting an NGO to support this work.
02:25
Yeah, I'm skipping this slide because there's going to be enough content. But if you want, we can discuss this separately. And I actually managed to get some help since last year. One is the first hire. I'm very happy about this. Adrian, I'm hiring part time.
02:40
He's a contractor based in New Zealand. If you want to work with him as well, openwork.nz is their URL. And on the Fediverse, you can find him under the address there. But I'm also getting some help from the Autonomic cooperative. It's a European cooperative made of more than, I don't know how many actually.
03:03
And seven great people. And specifically Rebecca is helping with design work a little bit. Oh, very, very happy to advertise their work because they're great people and you should hire them, but please don't hire them because I need them. Well, hire them part time.
03:21
That's, I think that's the compromise we should go for. Okay, so what's the sort of problem we're dealing with? We have human rights. I can't get into this in a moment, but in the digital realm, they're not always well represented. And I'll go through a couple of slides relatively quickly to
03:40
explain what I mean with this. First of all, we have, of course, human rights. And when we talk about human rights, we tend to talk about the UN's universal declaration of human rights, which here in Europe is really part of our constitutions. So that's the sort of point of view I'm taking. This declaration is not ratified everywhere and interpretations of
04:03
this might differ in different places, so I can't really speak for every place in the world, but that's sort of the point of view that I'm looking at. And this NDI initiative by the European commission keeps talking about an internet for humans or of humans. And I've used a similar term in the human centric internet
04:22
in the last, in last year's talk. And what we mean by that is basically the same thing is that if we want to create a future internet, that's unavoidably more strong, a bigger part of our lives than the internet is today already, then we have to start making sure that our basic human rights are not negatively
04:44
affected by the technology we use. And one of the ways, if you want to look at it in more detail, but one of the ways that this becomes manifest in this, is in this battle between stronger and weaker encryption, and both sides have an argument that they want to help prevent crime.
05:00
One take the point of view that weakening encryption is the right way to go, the other is that strengthening encryption is the right way to go, at least not weakening it. I'll spare you the discussion here, you can find enough about this on the internet and the global encryption coalition is a good starting point in my opinion. But what I'm trying to emphasize here is that both try to protect
05:24
people, we're both working towards the same goal from opposite ends of the problem space, if you want. And this is the current fight, right?
05:41
I mean, the question between a free software, open-source software, proprietary software, that's still an important thing that's ongoing, but the internet is irrespective, it's independent of the specific software that they're using to access it, so we have to also have the discussion about how are our rights reflected in this most basic
06:04
technology that is implemented in one of different software pieces. Once you look at the universal declaration of rights in more detail, it's a bit of a half serious slide. I'm not a lawyer, I'm sure my interpretation is wrong, but one of
06:21
the things that springs to mind is that it actually guarantees your privacy of correspondence and that could mean something like a rights to end-to-end encryption, and there are other things that you can derive from there to the digital realm, which aren't really reflected in national laws completely. I mean, there is something trickling down, of course, but we have
06:44
to also understand that some of these fundamental human rights are not really reflected in the technology we use, and that leads to us engineers to make choices. Now, I don't want to make this talk political, so I'm not
07:01
going to spend too much time here, but we have to understand that the stance of, I don't want politics in whatever project we have, always implicitly supports the status quo. It supports no change, whether for better or worse, not the point, right? It just supports no change. And the current status quo includes things like surveillance,
07:23
capitalism, voter manipulation, doxing, death threats, racist AI, tons of things that we as engineers, not specifically, but other than that, tons of engineering topics that we can address directly by our engineering choices.
07:42
I'm not trying to tell you what choice to make here. I'm just saying that we can ask ourselves daily, do my engineering choices help protect human rights? Do they hinder them? Do they have no impact? And this is how I come to the rest of architecture, because I am increasingly
08:00
of the opinion that rest is actually not particularly helpful in protecting human rights, and that's a big thing that we want to tackle this and change this, and that's sort of what the Interpeer project is all about. And then specifically it's the topic of this research on what do we see on the file side of REST. Let's talk about REST.
08:21
The term is from Roy Puelling's dissertation from 2000. Roy was working on standardizing HTTP, but REST and HTTP are sort of separate things, but HTTP is a particular protocol. REST is the abstract architecture, right?
08:41
And together they form the web, web, web, basically. It's important to understand that HTTP is not the same as REST. There are things in REST that are not HTTP and vice versa, but they're very similar. And even I will use the more or less interchangeably in the next couple of slides.
09:00
No. More importantly though, that REST has nothing to do with a particular software, a particular framework, or mapping HTTP methods to some sort of RUD style of programming. It has nothing to do with REST. RESTful, as we tend to use it on a daily basis, has nothing
09:22
to do with REST, the architecture. It's the same term. It's derived from this field in dissertation, but then got changed in a way that no longer has that much similarity with REST. What REST is, is abstract. It's a decentralized scalable architecture for networked systems, right?
09:43
And I crossed out the decentralized part here because I think some of the choices made in REST actually work against decentralization. I want to go into this in more detail. So here's the diagram of REST from this paper, from this dissertation, ignore most of it.
10:01
The important part is that on the left-hand side is a user agent and from it go paths A, B, and C, and it uses the same protocol, HTTP, to communicate along all these three paths. It doesn't know and shouldn't know whether one path takes it directly to a file system, the other path takes it via a proxy to some database, and the
10:22
third through a proxy, a gateway, to some origin server, the whole point of REST, write a uniform interface between these components that makes all of these layers transparent to the user agent. Okay. The REST paper talks about architectural properties.
10:41
You can think of them as goals. And it also talks about constraints, architectural constraints, which you can think of as requirements. And then it uses this terminology that a particular constraint induces a property. By what it means, what it means by that is that if you fulfill this requirement, the effect will be that you're reaching or getting closer to your goal.
11:03
I'm using the technology from the paper a little bit so that you can map this. If you want to read the paper later, you can, you can map one out into the other and Roy lists a couple of properties that he wants to achieve. Performance, scalability, simplicity.
11:20
I'll go through them briefly here. Modifiability, which again has a couple of sub-components, visibility, portability, and reliability. Then he derives constraints from this and asks questions of other architectures in the paper, does this architecture meet all of these properties? And some of them do, some of them don't.
11:40
And he derives from this REST with the arguments that is actually achieved all of these properties. Now I have no particular argument against that except in some detail. Let's explore the problems with this. Ah, hang on. Before we do this, if you look at HTTP as the, the, the, basically the only
12:04
protocol in existence that really tries to be a concrete implementation of REST, right, I'm sure there are others, but they're not as widely used. Then it becomes apparent, if you look at the history of its evolution, that it actually has no user interest in mind when it evolves.
12:21
Most of the evolution of it is driven by corporate interests. Google in particular. There are also no architectural changes. So the abstract point of view that REST takes is not really massively addressed in any of these HTTP iterations.
12:42
I'm being here a bit brutal when I say that it doesn't address security. That's not completely true. TLS sort of evolved alongside HTTP as a separate, separate layer protocol, but was driven by HTTP needs or at least to some degree, and then in HTTP3 there is
13:02
actually quite a lot of work dedicated to how HTTP and TLS should integrate. So it's not like security is not addressed, but consider that HTTP3 is not completely finalized yet.
13:20
And that means that in 2022, we don't actually have a real standard yet of dealing with security on the web. We have best practices, basically. So from a certain point of view, and I know this is a bit of an aggressive
13:42
point of view, but from a certain point of view, you can actually say that neither the concrete implementation HTTP, but also certainly not the architecture REST addresses security and neither of them have anything to do with privacy other than through encryption. So what problems do we have with REST or HTTP?
14:03
Well, one of the things that sort of become apparent is that when we talk about the web, everybody talks about different things and we have sort of three, three major use cases. I'm sure there are more, and I would like to hear from you what you think I missed here, but for now, between the conversations I've had
14:22
with people, I'm coming to the conclusion that there are three and there's some terms floating around that try to capture the best version of them. One is sort of the document web, which is what HTTP and REST were designed for. I publish a document, somebody else wants to read it, they download it. That's it.
14:40
And it's a very good fit for this kind of use case. Then with web 2.0, we started looking at the API web, where really the major shift is that a document is no longer something human readable. It's no longer meant for human consumption, but it's meant for machine consumption, but the request becomes some sort of structured data and
15:02
response becomes some sort of structured data, and we basically have remote procedure calls. But in an API communication goes in both directions. A lot of time it's driven by a client that wants to have some sort
15:21
of functionality involved on the server. And for that REST is fine. But when you have a different sort of use case where you want to be notified of something by the server, suddenly the request response paradigm doesn't really map well into this anymore. And so we have a lot of workarounds for this. We have polling, we have other things.
15:42
They do kind of work. It's not like engineers are shackles and can't get this kind of thing to work on the web. The point I'm trying to make here is that the web is not really designed for this at all. And all we have are workarounds. They work. But that's why I'm considering this a limited fit, the use
16:02
case to the technology, I mean. And then we have the streaming or the real-time web. I don't know how better to phrase it either, either one or the other works. The thing is with streaming take media streaming or video streaming in particular, as an example it's, it's quite well understood
16:21
that a lossy medium might actually be better for streaming than a lossless medium. What I mean is that if, if the frame rate of my video gets reduced from 30 to 28 frames per second or something like that, it's, it's very difficult for me to notice this, but if the playback stalls for a moment of stuttering, or if it stalls
16:45
for a longer time, like buffering, that is immediately noticeable and immediately degrades my experience. And that tends to happen when the application layer tries to request lost or missing data from the backend again.
17:00
So it would actually be better if the transport layer was losing the data and saying, Hey, sorry, I can't do anything about this anymore. Or the streaming use case, the same doesn't apply to the API or document use case, but what it means is that REST and HTTP are not actually a particularly good fit for the streaming web and still we use it
17:21
for that because what else do we have? There are a couple of different issues here to do with authorization. And basically because authentication authorization are not really all parts of the protocol. That means that the implementations, I want to skip through the details here a little bit because there's enough to cover, but the implementation
17:42
details tends to mean that the properties that the architecture wants to achieve are weakened in practice. It's not really a fault of REST as much as it's a part of the implementations on top of REST, but because REST doesn't consider
18:00
this, that's what we get. And so, you know, I consider it a REST problem in the sense of it didn't address this. Now, 20 years ago, more than 20 years ago now, it wasn't so urgent. I'm not blaming anyone here, but nowadays it's urgent and nowadays we have to acknowledge that REST is maybe not the best fit for this anymore.
18:21
More important than this is this representation nature of REST. Basically, if you don't send the data that the server stores over the wire, but some representation of it, right, that base document that you receive doesn't have to be stored as JSON on a file system, for example.
18:45
Because that's what you do, you gain a lot of flexibility, but it also means that the server determines the communications protocol to the client, which means it's impossible to write a generic client for the HTTP protocol.
19:01
You have to have a provision that the client can be extended with code and the REST architecture says, well, this should be optional, but in practice, we find that this is unavoidable because, well, because data and code get mixed together. So you essentially create data silos where you cannot access data without
19:20
having the code as well, and that in turn pushes towards centralization. And centralization can have all sorts of problems. The third issue that I should glance at is, the third set of issues, is a total line server paradigm is maybe no longer applicable nowadays.
19:42
If I have, if I look around me, I have, I counted earlier, I have about 10 computers lying around here right now. And if I want to synchronize data between them, the client-server paradigm doesn't really make much sense to me. Does my mobile phone and my tablet, which of them is the client? Which of them is the server?
20:01
And should I push from the client to the server or should I pull from the server to the client or how do I synchronize stuff with this? And the answer the REST provides as well, you can do this via some kind of centralized server. They're all clients and you need a server somewhere else in the middle of it.
20:21
It could be on my local network. It could be somewhere in the cloud. It makes no demands there, but it basically doesn't really care. It seems to, it views the world as client-server and with how many devices we have lying around these days, that doesn't seem to be the
20:41
most appropriate model any longer. Okay. So if those are the problems of REST, some of them very fundamental, some of them a bit more adjacent, how do we model new key properties and constraints that actually are in support of human rights? And that's sort of what we're working on right now.
21:03
First, this is my point of view. Tendrilizations at the core of many problems in particular, and this is where I invoke, you know, the elephant in the room, something like Facebook's, Facebook itself is not a centralized service. It, it, on the protocol level, it's decentralized, it lives on hundreds
21:22
of machines, maybe thousands, but as a, as a service, as an entity that collects data, processes data and spits out data again, it is a centralized service. And this is where surveillance capitalism thrives. This is where voter manipulation thrives.
21:41
This is where a lot of issues thrive because there is unlimited, almost unlimited access to such huge amounts of data that cross referencing them, it becomes a goldmine, right? So very hard to convince Facebook no longer to do this.
22:03
Um, but the alternative that I see as well, our technology should actually prevent this from happening ideally. So the key property that I'm most concerned with is in a way, is that all the other profits we're talking about are fine, maybe the rest ones are fine.
22:20
I'll add some more ones in the next slides, but all of them should encourage distribution and they must not require centralization. Now, Paul Baron, who came up with this diagrams and in this note memorandum that I'm quoting here, um, he was concerned with the resilience of communications networks in the face of attacks, right?
22:43
So somebody sends rockets at communication stations. How do we still, how do we still manage a line of communications? He came to the conclusion of the fully distributed system is best is best is most resilient. You can take this to the internet as well. And the same thing applies. You can take this to, to, um, the concept of a human network in a
23:07
community in the same thing applies. The moment you have a central focus for it, if the central focus falls out, the community dies. You have multiple smaller foci, you might have more chance of survival, but the best chance of survival for the community is if everybody knows many
23:23
people and, you know, stays connected that way. So this is a very human centric point of view, right? That's the point here. Other key properties is we have to take authentication authorization into the protocol. Um, they should be supported.
23:43
They should be default in some ways, but they must be, it must be possible to switch them off, which means we need to have anonymous users. We need to have public publishing, not just publish, publish into some authorized entity and so forth. Uh, we need to be able to support real time streaming in
24:01
a much better way than HTTP does. We need to support bi-directional users. So even things that the server initiates to the client, reachability refers to these devices lying around, right? Um, we should be able to reach any device anywhere in the world, ideally without sort of transport level constraints, such as a network, uh,
24:23
risk translation unit or something like that. And I really would like to have more generosity and by generosity, I mean that this, this, this munging of code and data into one lump is not necessarily good for, I'll get into the constraints.
24:44
Now, if we have an encrypted transport that induces privacy and it can help with authenticated users, we still need anonymous users. So authentication doesn't necessarily have to mean, I know where you live. Um, it can be, Hey, I've, I've spoken to you, I spoke to you before.
25:01
And that's, that's in, for many use cases, this is good enough. We don't actually have to open up the world for an effective use case. And anonymous can mean I've spoken to you before. And if I, as an end user can generate new identities all the time, and then I am also in control of how anonymous I am, I can decide to have one identity with
25:24
one service and another identity with another service and rotate one of them yearly and the other one daily. Oh, anonymous in this case is in the control of the user. Um, distributed authorization, um, should help with our authorized users.
25:42
Uh, we need a real time and lossy capable of transport. It shouldn't be just lossy, it should be lossy capable. Um, on top of the client server semantics, we should also be able to, um, implement publish, subscribe, submit semantics. Um, of course this is happening on top of HTTP as well.
26:02
If you look at activity pub, um, that's exactly what it's doing, right? It's, it's mapping a publish, subscribe, subscribe mechanism on top of HTTP. But that doesn't mean that HTTP supports this. It's just that it allows this. Next side note here, um, supporting and allowing, they're not the same thing.
26:23
Um, most programming, programming languages, for example, allow something like object oriented programming. Even C does and fill a struct with function pointers and you have an object. Uh, but it doesn't actually support it by which, uh, I mean, there's no syntax that makes this easy.
26:42
It's possible, but it's not particularly easy. You have to do it all by hand. And in the same way, I'm talking here about supporting, right? Um, HTTP allows map, publish, subscribe mechanism on top of it. It doesn't actually support this in any shape, way or form. Other constraints remain the same, the cache constraint, the uniform
27:02
interface remains the same that can layer systems remains the same. I would like to introduce a constraint local first, um, which really means in some way, it means that the location of the resource shouldn't be
27:20
as important as the identity of it. HTTP is all centered around URLs, URLs are locators. They actually contain the location part. No, that's the whole point of URL. Um, I don't think this helps. I think it actually hinders in the sense that yes, rest components can decide to hide the actual location from the user agent via some kind of
27:46
proxy mechanism, um, but you actually gain more cacheability. Um, you actually gain more distribution if you completely ignore location on some level and just speak about identity, this is the document I want to have.
28:04
That's the identity that I have for it. And then the system can decide whether it's, it's cached locally or not. I'd also like to see more purposeful representation. Basically we have a lot of documents now that will have a content type of application JSON.
28:21
JSON is a serialization format. It doesn't actually tell you anything about the data that's, that's contained within. There are document types for that as well, but they're not universally used. So if we require a bit more of something like content type specifier to contain
28:40
a little bit more of information about the purpose of the data, what it represents, then that might actually help with standardizing things. Uh, an example of this is OAuth, right? The authentication mechanism. Um, you can write, you can write your own authentication for your own web server.
29:00
OAuth is a nice standard that helps lots of parties to more or less the same thing. Um, why shouldn't this be the case for other use cases, like, like user profiles, like, uh, uh, you know what I mean, right? Um, and the answer is, well, there are no standards and there are no standards because you don't need standards.
29:24
I want to decouple code on demand from the data. Um, basically if we, in the current version of the web, we have this thing where code gets downloaded either automatically or deliberately, um, from a particular location, so in a way, the code that we download is coupled to
29:43
the location and I find this is where these data centers are happening. If we can couple the code more to a purposeful data format, um, that might actually be helpful. So we could have code that, that represents an edit form or user profiles.
30:03
And it doesn't matter whether the user profile is, uh, you know, tied to one service or another service. Um, the code can be more or less the same. Um, that's sort of the idea here. It should help with distribution, portability, privacy, and generosity. And to make this a little bit more powerful, we can also include, uh, a
30:24
property or constraint for data format transformations. And the example I'm having here is if I want to write a media player of sorts, like making simple audio player, I currently have to support many different audio formats and there are libraries that help me abstract this out a little bit, but still I have to do this.
30:42
What about taking a different approach? What about, um, writing my, my application so that it supports audio opus, for example. And then we have transformation code that we can invoke, um, that converts from or to audio opus from another format like speaks.
31:03
Suddenly we have separation between application code, um, this transformation code, data formats, and also data transport on some level. And each of these pieces can become more generic as a result of this. Whereas with the web, everything is managed together into one, and
31:21
we can't really make this operation. Of course, and this is very important to understand that which makes the web so flexible is that it doesn't require everything to be standardized. So we can't shoot ourselves in the foot here and require strict standardization of everything. Because at that point we're losing the flexibility, but we can encourage it.
31:45
Um, we can make it easier. We can make the framework in which we operate such that this is a normal way to operate. That's sort of the idea here. So as a simplified, very, very simplified new architecture, um, consider the browser
32:04
and any web application type thing that we're using. Actually have the same access to the same API. And this API then internally sort of decides whether to talk to a cache, whether to talk to this transformation subsystem, which might talk to the cache.
32:22
And the cache might just pass the requests through to the document web, to the API web, to the real time web in this kind of different types of protocols, either on demand, publish, subscribe, or some kind of mixed mode. Um, everything to the right of these document API and real time web boxes.
32:42
Um, that is same as in REST, right? Each of these can represent its own client using its own local API with its own local transformations and so forth to create a very, very deeply layered system. I'm not suggesting that this is all there is to it, but this is sort of the
33:01
core parts that we move some of this, this, um, into, into what I've named here, client side service. Doesn't have to be a service that's actually running on your box, but that might actually be the best, the best, um, best system might also have one in your NAS in your home that you contact or something like that.
33:23
The point is to move this, to provide a universal API to the browser, to the application that takes care of these distinctions between on-demand and real time and so forth. Okay. So concrete projects that we're working on. First, let's start with what's already mostly there and
33:44
continues to work as channeler. This is NGI zero funded. This is a transport or session layer protocol differences, blurs a little bit, also in TCP with multiplex channels. And each of these channels can have individual reliability capabilities. So what I mean is this, you can create a connection from one machine to the
34:04
other, and you can say, okay, I want to open a channel now on this connection, but this channel should be lossy. And the other one should be lossless and you can negotiate other parameters for each channel. And that way, um, you can, um, channel this comes from, you know, uh, data
34:26
from, from one, from one, uh, uh, node to the other with a specific purpose and the transport meets the requirements of this purpose, including streaming, but also something like HTTP. There's a lot of similar concepts here to HTTP three.
34:42
Uh, it's sort of evolved in parallel, but the main difference here is that, um, there are no, no HTTP semantics in this whatsoever. It's much, much smaller, much more bare bones than this. The channeling is kind of done mostly at the time of speaking. I hope before first and it's actually done, done, but at least it's close.
35:04
Um, the next big thing is to put encryption there. Um, it should be a little bit like why I got with Maxtras basically. Um, now I put the network layer here as well. Um, cause I've tried to design, design this protocol so that it can
35:20
move towards the network layer. So transport layer is something like TCP, UDP, network layer, something like IP. Um, in order to do something like in order to use this protocol with something adjacent to IP, right? Not built on top of IP, but adjacent to IP. Well, we would have to have, we would have to deal with routing at some point.
35:43
So there's a research topic here for the future. How do we do deal with routing in a way that's nothing to do with IP. Completely unsolved at this point. You know, if you don't have anything for the future, what are you doing? The next piece of work is sort of, um, after the encryption channeler,
36:03
if you want, is, um, and currently unnamed protocol. Um, also NGI is also part of the NGI funding, which is more on the presentation layer. Um, it's supposed to give these random access and streaming modes of, of transporting data with a publish-subscribe mechanism as well.
36:22
Um, and in that it actually is very similar to something that already exists. That's PP-SPP, there's an RFC for that. Um, the main difference here again, is that the PP-SPP makes some assumptions about the transport that aren't ideal specifically, and this is a quite a
36:40
complicated way really to, to go about it, it's implemented on top of UDP. Or at least it says, the RFC says it's implemented on top of UDP, but then it requires, um, round-trip times from the transport layer, and round-trip times don't exist in UDP, they exist in TCP, or you can add them manually yourself.
37:02
And as such, it's actually a bit unclear how PP-SPP is supposed to be implemented precisely. Number one. So that's something I will have to address in this work. And the second thing is that for the streaming access for this publish-subscribe access, right, it's probably best to enable, at least in some cases, enable
37:24
the lossy behavior of the transport, which means that there needs to be some sort of communication between the presentation and the session layer. Uh, I've said in the past that this sort of breaks the Aussie layering. Um, and then I was corrected by a professor at some point in different
37:42
unrelated projects, I said, no, actually this is an exercise in abstraction and layering, it just means that we have to also talk about the interface between these two layers and maybe expand the interface somewhat, and that actually is strengthening the layering rather than weakening it, and, and has a point, but
38:00
I like this because this, that's why I quoted this, it's an exercise in abstraction in some ways. PPSPP seems to have no view into the transport, but has a couple of conflicting assumptions. That's the way I'm reading it, right? And correct me if I'm wrong, I also want to hear about that. And in a lot of ways, what I'm proposing here is to make, bring
38:23
clarity there in this dependency. Okay. But let's assume we have this and we have a transport presentation layer protocol really that can access resources without understanding anything about them in a streaming fashion or in a random access fashion.
38:43
Okay. Next topic. Um, this is actually part of the ISOC grant now. Project I'm calling Caprock. Um, it's on distributed authorization and it's based on a lot of prior work. No, I'm, I'm basically hardly ever inventing something here. It's just reading a lot from different people and shuffling things around
39:03
until they fit a little bit better. Um, so, um, the basic idea is that in, instead of having some kind of authentication server that says, well, this operation is okay, nine can present a token, something that's serializable, that's transmittable over the internet that proves that they're allowed to do what they're asking to do.
39:25
And, um, probably this, this, this project will cover some other AA topics, but, um, I'm not really, I don't really have anything particularly concrete in mind right now, but there are other topics we have to solve.
39:40
And that's then a good umbrella for this. So that's something I only just started. And if you have any, any thoughts on the matter, I would really like to hear from you. Um, so this whole thing is based on OCAP, object capabilities. This is an old concept for inter-process communication
40:01
in a local machine, basically. Um, there are programming languages that sort of try to support this. Um, I know that, that, um, Christine Lemma Weber, who, who, uh, was previously working on ActivityPub is now, um, also working on a project to use OCAP in a distributed object oriented, basically, um, programming environment.
40:26
And I think there's going to be some overlap here. Maybe we can find a way to, to, um, work together on this at some point, but for the time being, I'm not actually looking at something concrete, like one object invokes a method of another, which is what she's doing.
40:41
But, um, I'm looking at the very basics, right? This is the content that token needs to contain in order to be provable, basically. Um, I kept expanded on the OCAP to make this, um, suitable for networked IPC authorization.
41:01
Was very strongly critiqued. I found that a little bit surprising, um, because it relies on some centralized components, for example, for your occasions of authorization. And it makes assumptions and no longer hold because it sort of says, well, you know, this thing may be a little bit too hard to compute on a, on a computer.
41:20
That thing might be a little bit too hard to compute on a computer. Turns out we're doing this all the day, all day, every day now, with our even small sort of embedded machines. So we can actually find some slightly different solutions to what was found there nowadays. There's also some relation to JWT, JSON web tokens.
41:42
Um, they're really more of a multipurpose token, but they can, of course also contain authorization data. And there is another RFC which sort of combines OAuth with JWT. Um, so you might think that it's already solved that the thing is OAuth requires a centralized authorization server and the whole point of, of this
42:04
little project here is to not do this anymore. Um, what we could do is for example, use JWT as a, as a serialization format. And I don't think that this is a wrong idea, but, um, that's sort of the relationship here. All right. And it's also interesting that the vocations are actually a particularly
42:23
difficult topic and also TLS. Um, so for example, faces this, um, and there's, there's our C5280 to address this in TLS, um, but that also requires some kind of relatively centralized, um, certificate revocation list, which I'm trying to avoid here
42:42
in this work, but we'll see how far it goes, but that's sort of the goal. Try to avoid the centralized components. The other bigger ISOC funded project is weird. Uh, this is where Adrian is helping currently, and I'm sort of supervising and I want to help as well, as much as I can.
43:02
When, when I made some progress with the others, um, and the whole point here is to treat documents as a series of changes, um, in the abstract. Um, so you can think of a document as a sequence of segments or blobs, right?
43:25
Um, and so one of the operations to update a document, one of the simplest operations you can imagine for updating a document is to append more binary data to what already is binary data here that might not be the most efficient one, but at least it allows streaming, right? It's, it's, it's not, it doesn't buy you very much, but it, it, it
43:44
allows streaming data, it allows incremental updates to the data at the end. Um, if you want to have a more complex case, then, um, you can go, and that's probably the best currently known cases to implement a conflict free
44:00
replicated data types, where, um, each change is kind of operation, insert, remove, replace, that kind of thing. Um, of a particular location in the final with some new data. And in a way, this looks a little bit like Git. That's why I mentioned this here.
44:20
Uh, Git works on patches, which are sort of line-based, um, CRDTs, you can think of working on structured data instead. Uh, and so the thing for weird is that we should have a sort of a framework for plugging in these different types of ideas of how a document is actually a
44:42
series of changes into an overall system so that the API end of it doesn't really need to care so much about how it's happening in terms of data being transmitted or stored. It just has the results at the end. And so it's supposed to sit between the API on the one hand, the API to the
45:02
applications on the one hand and the presentation layer protocol that can transmit stuff in chunks or subscribe to resources on the other side of it. That's sort of the purpose here. Um, I said this before that HTTP has this obsession with, with location. And, um, another way of looking at this is that actually there is no concept in
45:25
HTTP of saying, well, I want to download this resource that that doesn't really exist because what HTTP actually says is I, I think I want the resource that lives at this location. That's what it says. And then there are a variety of headers in HTTP that narrow this down, right?
45:44
You can have an ETag header, you can have a cache control header and so forth that, that, that sort of forces a certain freshness of the data that sort of tries to say, well, it shouldn't be, it should be newer than what I already have, that kind of thing. But at the end of the day, the server is still allowed to send you whatever it wants as a result.
46:02
And for example, especially when it comes to things like authorization, if you don't have authorization to request the resource, it might actually send you back an error message rather than document content. And it's very hard to, to, to treat these at the same thing. It's not the document I want that I'm getting, I'm getting something else entirely, and that is an error sort of incidental in a way.
46:25
If you want to see this complexity, Mozilla has put together a pretty good document on HTTP caching. It's very long and it's not even covering everything. I think, if I remember correctly. So one way of looking at this then is to, for weird is to provide a uniform
46:42
interface with significantly reduced complexity when it comes to handling this idea of which resource am I actually getting and then efficient implementation via this presentation they are going to call it. So we want to reduce complexity.
47:01
That means at some point we have to do something that REST and HTTP never explicitly is to say, actually, we know that there might be multiple versions, multiple versions of a resource. We can't give a single name to all these multiple versions. Let's, let's embrace the fact that multiple versions of a resource exist and then give very explicit control to the application, which
47:24
version they're actually talking about. And that could mean the latest, right? That's mapping to REST again, basically. But then otherwise try to stay out of the way of document formats, because that's not really the point here. The efficient implementation means that weird has to understand the boundaries
47:45
of changes by which I mean, if you have a data stream, it needs to understand at which byte offset does a change start and end, because without knowing this, it doesn't know how to map this well onto the IO subsystem, whether it's the network protocol or a local cache or something.
48:02
It doesn't really have to know much more about the contents of each change. It has present uniform interface. So the application can either just handle file like objects and get the latest or the latest that's available or whatever the client request was. But we can also provide a sort of uniform API for treating the document
48:25
actually explicitly as a series of changes or content operations. I'm talking about them here now. And that's really the tricky and interesting part that Adrian is working on right now, how to define this in a way that's sort of independent of the actual implementation of the change sequence, whether it's a block
48:45
based or CRDT based or something. And weird is supposed to be a framework for many different implementations of this kind of overall logic, which means that in addition to a document type, content type, right, we're also sort of dealing with a content
49:05
type for the kind of CRDT-ish construct that's underlying that thing. Okay. So that's ongoing projects. If you're interested in any of them, reach out. I'm sure we haven't covered everything.
49:22
You can use all the help we can get and not honestly, there's a lot to do. And, but that's not where this ends, right? We have good building blocks then on the transport level, we have good building blocks more towards the application level, but then we have to do a couple of other things I mentioned already routing, and then we have to deal with
49:43
discovery, which is also already partially funded, so like a distributed hash table. It turns out we have some overlap here with the LibraCast project. I'm very happy. So another NDI funded project, and I'm very, very happy to be talking to them. And they're really nice people.
50:01
They're trying to solve multicast in current IP, right? They're not trying to involve inventing new protocols like I'm doing. They're trying to solve this in current technology stack because they consider multicast to be the solution to many of these issues and they're right. But what they're doing then as well is write protocols by which
50:24
routing information gets propagated. And the problem with multicast on the internet right now is that not all of these protocols are well supported for a variety of reasons, and so they want to push that development again.
50:40
The protocols themselves, or the algorithms at least, they probably mapped 100% to what we're doing here. So I'm very happy to know that they're nice people that you can talk to about these topics very easily. And we want to exchange information and cooperate and that we'll have to see how much overlap there is in the end, but if we can benefit from
51:03
each other's ideas, that's going to be a great thing. The second thing is that this whole data transformation framework I was talking about, it isn't really part of weird, it should have the same general API so that the API and the application doesn't really see a difference
51:20
between a data transformation, transformed data and raw data, if that makes sense, but it should probably be a layer on top of weird or, you know, both should be hidden under the application level API in some way. And one of the interesting things is that one of the most powerful use cases here is actually that this data transformation can happen
51:41
on the server side or what we now consider the server side. One of the things, for example, that we can deal with is provide a reduced site proxy of some object, apply abstract transformations via the weird CRDT to it. And then the server side applies this again to the full-sized large resource.
52:06
And in that way, we save bandwidth, we increase, improve the user experience, but we don't actually transmit tons and tons and tons of data. And there are some real-world use cases where that would
52:20
actually be very, very useful. So this is certainly an important research topic for the future. And then of course, we have a lot of glue. I've presented you with a lot of pieces here and you know the 80-20 rule, the Pareto principle, 20% of the work takes 80% of the time.
52:41
So there is going to be a lot, a lot, a lot of work to put all these pieces together into a working whole. Yeah, long, long future ahead. So, contributing, how can you contribute? Very simple.
53:00
First of all, ask us. No, you can ask, I see chats and you can go use your matrix bridge or whatever as well. Just ask around, look at issues on GitLab or donate. I don't, it feels wrong to beg for money when I've just told you how I
53:26
actually already have money coming from two sources, from Anairnet and from ISOC. So if you don't want to give me more money, I completely understand this. If you do have money to give, give them to Anairnet or ISOC instead. That is a really good start because they're funding projects like this one.
53:46
And then of course, though, part of the reason I started the NGO is in order to receive donations and write donation receipts. And the point here is not that there's not no money to fund this. The point is that grants, research grants, tends to cover specific topics and it
54:04
means other things for, by the wayside a little bit. There is very little you can do for bug fixing and just stabilizing software with a grant. It's possible according to, in some grounds, right? But it's not really what research is all about.
54:21
Administrative work, IT ops work is just not really very well covered by this and that's always going to be a factor in this kind of thing. So if you do want to contribute to this with money, once the NGO is up and running, please, please reach out. I am very, very happy about this, but I can also understand that donating to
54:43
more, more established foundations like Anairnet or ISOC is more your thing. Okay. Do we have any questions? I see now we're almost 55 minutes. That leaves about five minutes for questions.
55:00
So I'm going to stop at the video here. Thank you for listening and goodbye.
55:24
Let's see that. So it'd be like, yeah, we are actually live. Yeah. Let's see. I don't know if, if there are any questions that I can.
55:44
Yeah. Okay. Guys, if you like, if you have any questions for Jens, you can just, um, yeah, I know. I don't know if I said this just now, but, um, I know there are Tronov projects who are looking at similar, similar things.
56:02
Right. And I'm very happy if people point me in the I'm confused by the delay. Sorry. Yeah. If I see any, any more questions, I just saw, I was directing to a
56:21
question to a comment that, uh, there are other projects out there that do something similar. I am looking at whatever I can find. Yes, basically. Um, so any tips there, I'm always welcome. Uh, yeah, I'm not sure if there are more questions coming in because, uh, I
56:46
think I've replied to most of the ones in chat. Yeah, exactly. So next step is probably, uh, take a look at the RFC on the, otherwise I'll just hang around and look like an old guy with a beard for five minutes.
57:03
It's also okay. I can do that. Doesn't look like there's that much of a delay, by the way. Yeah, nothing, nothing, nothing concrete now. Um, yeah, every, every project I look into, uh, in this space gives me
57:25
something, something very interesting to read and, and, and sort of inspires a new idea. Um, I have to say there's a lot of good stuff there and every project I find, I also go, but they're not really accounting for this.
57:42
Um, so if you're asking why, why am I doing this is because of this last part, uh, I tend to, I tend to see gaps there, uh, and, and without going into, into very deep detail is very hard to answer in a couple of minutes.
58:03
Um, so yeah, just as a general comment there, um, the, the best, the best example that, that I had in the talk was the whole point about streaming on the web, you know, we have WebRTC that's that's happening in this room here, but it's not really part of, of, of the REST architecture. It sort of bypasses the REST architecture and it works as a transport.
58:24
No, no doubt about that. There's another question about, uh, the chat room and it's sort of talking to an empty room. I, I guess, I guess there are no more questions, right?
58:41
There is one, there was one question, uh, from Tess is it's only, do I see some that I haven't had that I've missed? He was asking if there's a, is there a matrix room?