It’s an interesting design decision to make every node carry the entire data-set of the network. This is plausible since the content is text-only and everything expires after six months. Problems I see are:
Even text is big, in sufficient volume. And there’s going to be a lot of metadata (the graph structure) that doesn’t compress as well.
Initial bringup on a new client machine could be slow. That was my experience with Scuttlebutt: I ended up with ~1GB of data just from connecting to one pub and following a couple of people, and it took hours to do so over a fast broadband connection, presumably due to protocol complexity and client inefficiency.
This could use more storage space and bandwidth than I’d want to give it on a mobile device. I shouldn’t need a huge global corpus on my phone just to be able to look at new stuff while I’m in line at the grocery store.
This being decentralized, if it succeeds there’s inevitably going to be a buttload of really offensive and/or illegal content on the network. Do I want my storage space being used for QAnon/Nazi/pedo content, and my bandwidth used to help distribute it? Are there legal implications to having this on my disk even if I never read it (in any legal jurisdiction?)
Even with proof-of-work required, how hard will it be for griefers with ASICs to flood the system with spam / abuse / trolling? Plus s/griefers/botnets/ or s/griefers/state-owned actors/.
The voting system is really interesting. It sounds like it may be vulnerable to takeovers of a group, though. Their FAQ acknowledges this, but it seems like the proposed solutions don’t yet exist.
For reference: in 1993 or so, I was running a Usenet news server (no binaries groups). Things were flat out… with 3 Mb/s of bandwidth, a 150MHz Pentium and 6 2GB SCSI disks. I think. It’s been a while. INN lives.
These days, a Raspberry Pi can outclass all of that.
I wonder if the data is structured (or let’s say “easily enough queryable”) that you could ask the user on first login if they want “everything”, or center on one “structure”, like the motorcycles forum example, or time-based “give me all posts in the last 24h first”.
Yes it is, we even have our own internal query language that can do this, though not yet exposed to the users. If you have the software skills, it’s simply filling out a gRPC API call.
Aether is a relatively large app with an Electron and Go toolchain, at 100,000+ lines of code. Getting it to compile requires setting up a correct build runtime with the latest versions of Go, Node (for Electron) and C dependencies and development environments. Expect the initial set-up to take a few hours. Be patient!
I’d be OK with a background HTTP server, and opening a localhost:8888/ type URL in my browser. At least that isn’t going to install gigabytes of Chromium and V8 source code and binaries on my system.
There are also a couple of cross-platform libraries that build tiny native app wrappers using a WebView (or whatever your platform calls it.)
Hm, that’s an interesting problem. A common criticism of AGPL-licensed software is that it does not directly tell the user how to obtain source code, which frustrates the requirement of the AGPL that the software be explicit with the user about how to build and run their own version of the software. The text of the AGPL appeals to “some standard or customary means of facilitating copying of software,” but Aether doesn’t appear to have such a means.
We have the source code on the website (I think, if that’s not the case, it’s a bug) — it used to be very much up in the front on the download page. However, what happened is that we have a lot of novice users (the goal of the project is exactly that: P2P for the masses), and they ended up downloading source code, and then start creating tickets en masse on how to install this. Eventually, the solution ended up being putting the source in where developers can find, and let the downloads be where everyone can find it, and it mostly solved the problem.
The text of the AGPL appeals to “some standard or customary means of facilitating copying of software,” but Aether doesn’t appear to have such a means.
Quick nit to highlight a mistake that I find a lot of people making: AGPL is a license to other people that we grant in using the source code. In other words, we (as in, people who maintain Aether P2P, that is, mostly me) do not need a license for the code, because we own the code. Indeed it is because I own the code I can license it to others under AGPL. My relationship to the code is one of ownership, not licensing, so AGPL does not come into play. If this sounds surprising, Kyle Mitchell (https://writing.kemitchell.com/) does a good job of explaining the basics of software licensing in blog post format.
My relationship to the code is one of ownership, not licensing, so AGPL does not come into play.
Certainly. The main point of the critique is not that the license is not being upheld, but that there’s an opportunity to make the copyleft structure more rigid. If Aether were to offer a standard API for exporting its own source code to users, then any published modification of Aether would have to either leave that API as-is or modify the API and include their own source code in the modifications. This functionality would force folks publishing modifications to decide how they’ll fulfill the terms of AGPL.
For some software, this sort of argument makes little sense. MongoDB, for example, simply did not have such an API. It could serve many documents, but its own source code was not among those documents. But for a distributed forum, especially one which enables the distributed development of software, perhaps it is feasible. Certainly there are niches, like package management, where we might expect AGPL-licensed package managers to always export their own source code via the same APIs which deliver other packages’ source code.
Ah, very interesting. Yes, I remember such proposals from the OSS discussions from the ye olde days. I think that’s a good way to ensure that the software itself enforces AGPL.
The issue there is that in compiled languages that is pretty hard to do, since the binary executing at runtime does not itself have access to its own source code. In Python, for example, since it is interpreted from the .py files which have to be there in human readable form (well, barring .pyc use), the app can access its source code as raw files at runtime. That is not true for C, C++, Go or Rust. It is certainly possible to have a method that returns the app’s source code as a string or something that is of that sort, but that would involve the app containing its entire source code as a string, as a separate copy, and changing the source of the app that gets executed would not change the source code that would get served, so the app would keep serving the old, unmodified copy of the source code that is embedded into the app as a string, not the source code that runs, which the app cannot access or inspect. So that would not work as a way of self-enforcing AGPL.
I think that’s much better suited to interpreted, script-based languages since they at least retain some semblance of access to the source code at runtime. I guess you could try to export and deliver the machine code at runtime in case of a compiled language, but I suspect that’d be of limited usefulness in a real-world, practical context.
Yes. For a real-world design, we might want runtime code validation, so that we can prove that objects which publish their own source code are honest. We might also want a JIT so that we only emit native code after we’re finished proving properties about the high-level source code.
Aether is a flood protocol. Its network topology is effectively only concerned with delivering all data to everywhere, regardless of who’s following whom. It is designed to create a public space for people who don’t know each other to talk.
This means you can join Aether, post something, and your content will be visible to everyone even if no one is following you.
Maybe I’m overly pessimistic, but all I can imagine are now trolls and spam. They talk about some rules but I didn’t find any details
As a tradeoff, Aether makes it so that the only content that is directly postable to the network is text. Other types of rich media, like images, videos can be linked, but they cannot be posted directly into the network like SSB can.
So there’s not guarantee (if you can call that) that linked media is preserved for the 6 months it’s running. Maybe not as bad as it sounds, but I know people (incl. me) who for example post(ed) photos to Instagram to have a place to have a few certain pictures, tied together and deliberately not putting them in some pics/ folder on our own domain.
Also,
Aether is a relatively large app with an Electron and Go toolchain, at 100,000+ lines of code. Getting it to compile requires setting up a correct build runtime with the latest versions of Go, Node (for Electron) and C dependencies and development environments. Expect the initial set-up to take a few hours.
Oh wow, very confidence-inspiring. Distributed protocol? Go should be enough. Lines of code? Don’t matter. Electron? I can live with that. But I find it a weird choice of tools, in this combination. The setup sounds actively developer hostile. The build chain at my last job was horribly complicated to other things I know, but the manual process only took like 15min, then it was compiling for hours initially. Maybe that’s what they mean but I somehow doubt it…
Oh wow, very confidence-inspiring. Distributed protocol? Go should be enough. Lines of code? Don’t matter. Electron? I can live with that. But I find it a weird choice of tools, in this combination. The setup sounds actively developer hostile. The build chain at my last job was horribly complicated to other things I know, but the manual process only took like 15min, then it was compiling for hours initially. Maybe that’s what they mean but I somehow doubt it…
Sorry — being developer hostile is not the intention. The app is actually just Go, with an UI is Electron. C dependencies are pulled in because of SQLite, which backs the core storage of the app.
A few hours quote is unfortunately true for most people. For a competent developer it’s 20 minutes at most — but we do have a fairly non-technical user base, which is cool, one of the main aims of the project is that: P2P for the masses. But the flip side of that is that there are a lot of people who go in and create tickets with very little actual knowledge of software, except perhaps a few simple apps in JavaScript, and expect this to be similar. So ‘hours’ is an indicator for that for those people, to communicate that this is more akin to a C codebase than a JS website. Aether ‘using’ Electron is slightly misleading that way because it creates the impression that the actual app is JS or even, simple. We do not do anything except UI in Electron. It’s pretty much a Vue.js container that draws UI based on gRPC calls. The actual app is Go.
On the other hand, if you’re a C developer, there’s a makefile in there, you know what to do, go nuts. That’ll be seconds and single digit minutes for you.
Fundamentally I do Aether P2P on my free time and these support tickets directly eat away development time, so I have to make some hard decisions on what to prioritise.
Thanks for the detailed reply, that sounds a lot better
I think the Electron “frontend” is enduser compatible enough, while the whole premise sounds more like “with enough developer time we could probably have a working library and an alternative client”.
Yes, the app is very componentised. It’s in three, self-contained, separately-compilable pieces that talk to each other via a public gRPC API: the backend, the frontend and the client. Electron is only the client. The backend communicates over the network and keeps your local database up to date. The frontend compiles that backend database into network of data that you can browse via the UI. The intention is that you work on the part you’re interested in by replacing a modular component while keeping the rest of the app the same.
Usenet started with no central servers. It didn’t even use ARPAnet. It was just a group of mainframes & minis that dialed each other up by modem and exchanged messages … literally a 1970s P2P mesh network. Even in the ‘80s, when much of it ran over P2P ARPAnet, there were still a lot of servers on dialup — I had friends at a startup in 1991 who used one of their PCs as a news server, calling some upstream server once an hour or so.
Aether is a flood protocol. Its network topology is effectively only concerned with delivering all data to everywhere, regardless of who’s following whom.
is there anything stopping a person from encoding copyrighted material (or something much worse) as plaintext and then forcing every other node to receive it? I guess Usenet faces a similar problem, but they just don’t care/they have killfiles, right? If I’m hosting a node, can I opt out of hosting stuff I don’t like? Sorry if this is answered in the FAQ, but I couldn’t find it.
We do have some equivalent of killfiles that can be shared between users and the app supplies a default one as well.
Hosting stuff you don’t like: this is actively being worked on. Aether being a flood network makes having ‘incomplete’ nodes (i.e. everything sans the stuff you don’t want) a little challenging because the core assumption is that every node is equivalent to each other, but it’s not an impossible problem to solve.
I’ve done some thinking about similar systems. My current working hypothesis is that you can keep the digest/signature metadata of a post, but not the data itself. That way your Merkle tree or graph or whatever is intact, but stuff you don’t want is just skeletal.
You can do this, we in fact do this in Aether, it’s called the manifest and it’s the first few pages of any node’s payload. However having the manifest only makes you aware of what you have missing (i.e. saying ‘this node does not have these data’) but it does not tell you anything about where that data actually is.
The usual solution to this is to stick a DHT in front of it but DHTs fail at 30%+ attrition rates. That means, for it to work, out of 10 people that download and start the app, more than 7 will need to stay for the long term, so that DHT can reliably stick indexing data into them. That is a big ask, and it is not enough resilience for a P2P network that purports to ‘just work’, and not ask its users of making sacrifices because it’s P2P.
A while ago I checked out the docs of the Mim protocol, which Aether uses. Are there any other applications that you know of that are using Mim?
One thing I noticed is that, like SSB did with Node’s Json.stringify, Mim relies on the output of Go’s json.Marshal to compute and verify fingerprints and Proof of Work.
I’d recommend that you introduce some canonicalization step in the protocol before it causes any headaches in the future. All attempts at building SSB clients had a really hard time w.r.t this (including my own, I had to fork a json library and modify it to become compatible with Node’s). SSB is in the process of transitioning to a new feed format that uses CBOR instead of Json, which supports a canonical ordering.
1). Add source code to the download list, as an archive and as a link to some git repo. Right now it’s rather unintuitive to find where the source code lives.
2). Add a users guide that is easily visible and show people how to elect, filter, vote, block, delete, etc. from the js client since, again, it’s rather unintuitive how to do it.
3). If possible post a repo of the website so people can send you UX improvements without needing to email and asking for the source code.
Some thoughts:
It’s an interesting design decision to make every node carry the entire data-set of the network. This is plausible since the content is text-only and everything expires after six months. Problems I see are:
The voting system is really interesting. It sounds like it may be vulnerable to takeovers of a group, though. Their FAQ acknowledges this, but it seems like the proposed solutions don’t yet exist.
For reference: in 1993 or so, I was running a Usenet news server (no binaries groups). Things were flat out… with 3 Mb/s of bandwidth, a 150MHz Pentium and 6 2GB SCSI disks. I think. It’s been a while. INN lives.
These days, a Raspberry Pi can outclass all of that.
I wonder if the data is structured (or let’s say “easily enough queryable”) that you could ask the user on first login if they want “everything”, or center on one “structure”, like the motorcycles forum example, or time-based “give me all posts in the last 24h first”.
Yes it is, we even have our own internal query language that can do this, though not yet exposed to the users. If you have the software skills, it’s simply filling out a gRPC API call.
they don’t make it really easy to find so a Github link to AGPL-3.0 licensed code: https://github.com/aethereans/aether-app
They don’t make it really easy to build, either:
😩 I’m so tired of Electron.
Until there’s a distro package, building against GTK or KDE is also frustrating. Everything FOSS GUI sucks, that’s all.
I’d be OK with a background HTTP server, and opening a
localhost:8888/type URL in my browser. At least that isn’t going to install gigabytes of Chromium and V8 source code and binaries on my system.There are also a couple of cross-platform libraries that build tiny native app wrappers using a WebView (or whatever your platform calls it.)
Hm, that’s an interesting problem. A common criticism of AGPL-licensed software is that it does not directly tell the user how to obtain source code, which frustrates the requirement of the AGPL that the software be explicit with the user about how to build and run their own version of the software. The text of the AGPL appeals to “some standard or customary means of facilitating copying of software,” but Aether doesn’t appear to have such a means.
We have the source code on the website (I think, if that’s not the case, it’s a bug) — it used to be very much up in the front on the download page. However, what happened is that we have a lot of novice users (the goal of the project is exactly that: P2P for the masses), and they ended up downloading source code, and then start creating tickets en masse on how to install this. Eventually, the solution ended up being putting the source in where developers can find, and let the downloads be where everyone can find it, and it mostly solved the problem.
Quick nit to highlight a mistake that I find a lot of people making: AGPL is a license to other people that we grant in using the source code. In other words, we (as in, people who maintain Aether P2P, that is, mostly me) do not need a license for the code, because we own the code. Indeed it is because I own the code I can license it to others under AGPL. My relationship to the code is one of ownership, not licensing, so AGPL does not come into play. If this sounds surprising, Kyle Mitchell (https://writing.kemitchell.com/) does a good job of explaining the basics of software licensing in blog post format.
Certainly. The main point of the critique is not that the license is not being upheld, but that there’s an opportunity to make the copyleft structure more rigid. If Aether were to offer a standard API for exporting its own source code to users, then any published modification of Aether would have to either leave that API as-is or modify the API and include their own source code in the modifications. This functionality would force folks publishing modifications to decide how they’ll fulfill the terms of AGPL.
For some software, this sort of argument makes little sense. MongoDB, for example, simply did not have such an API. It could serve many documents, but its own source code was not among those documents. But for a distributed forum, especially one which enables the distributed development of software, perhaps it is feasible. Certainly there are niches, like package management, where we might expect AGPL-licensed package managers to always export their own source code via the same APIs which deliver other packages’ source code.
Ah, very interesting. Yes, I remember such proposals from the OSS discussions from the ye olde days. I think that’s a good way to ensure that the software itself enforces AGPL.
The issue there is that in compiled languages that is pretty hard to do, since the binary executing at runtime does not itself have access to its own source code. In Python, for example, since it is interpreted from the .py files which have to be there in human readable form (well, barring .pyc use), the app can access its source code as raw files at runtime. That is not true for C, C++, Go or Rust. It is certainly possible to have a method that returns the app’s source code as a string or something that is of that sort, but that would involve the app containing its entire source code as a string, as a separate copy, and changing the source of the app that gets executed would not change the source code that would get served, so the app would keep serving the old, unmodified copy of the source code that is embedded into the app as a string, not the source code that runs, which the app cannot access or inspect. So that would not work as a way of self-enforcing AGPL.
I think that’s much better suited to interpreted, script-based languages since they at least retain some semblance of access to the source code at runtime. I guess you could try to export and deliver the machine code at runtime in case of a compiled language, but I suspect that’d be of limited usefulness in a real-world, practical context.
Yes. For a real-world design, we might want runtime code validation, so that we can prove that objects which publish their own source code are honest. We might also want a JIT so that we only emit native code after we’re finished proving properties about the high-level source code.
Hmm, looking at the Mastodon and SSB comparisons:
Maybe I’m overly pessimistic, but all I can imagine are now trolls and spam. They talk about some rules but I didn’t find any details
So there’s not guarantee (if you can call that) that linked media is preserved for the 6 months it’s running. Maybe not as bad as it sounds, but I know people (incl. me) who for example post(ed) photos to Instagram to have a place to have a few certain pictures, tied together and deliberately not putting them in some pics/ folder on our own domain.
Also,
Oh wow, very confidence-inspiring. Distributed protocol? Go should be enough. Lines of code? Don’t matter. Electron? I can live with that. But I find it a weird choice of tools, in this combination. The setup sounds actively developer hostile. The build chain at my last job was horribly complicated to other things I know, but the manual process only took like 15min, then it was compiling for hours initially. Maybe that’s what they mean but I somehow doubt it…
Sorry — being developer hostile is not the intention. The app is actually just Go, with an UI is Electron. C dependencies are pulled in because of SQLite, which backs the core storage of the app.
A few hours quote is unfortunately true for most people. For a competent developer it’s 20 minutes at most — but we do have a fairly non-technical user base, which is cool, one of the main aims of the project is that: P2P for the masses. But the flip side of that is that there are a lot of people who go in and create tickets with very little actual knowledge of software, except perhaps a few simple apps in JavaScript, and expect this to be similar. So ‘hours’ is an indicator for that for those people, to communicate that this is more akin to a C codebase than a JS website. Aether ‘using’ Electron is slightly misleading that way because it creates the impression that the actual app is JS or even, simple. We do not do anything except UI in Electron. It’s pretty much a Vue.js container that draws UI based on gRPC calls. The actual app is Go.
On the other hand, if you’re a C developer, there’s a makefile in there, you know what to do, go nuts. That’ll be seconds and single digit minutes for you.
Fundamentally I do Aether P2P on my free time and these support tickets directly eat away development time, so I have to make some hard decisions on what to prioritise.
Thanks for the detailed reply, that sounds a lot better
I think the Electron “frontend” is enduser compatible enough, while the whole premise sounds more like “with enough developer time we could probably have a working library and an alternative client”.
Yes, the app is very componentised. It’s in three, self-contained, separately-compilable pieces that talk to each other via a public gRPC API: the backend, the frontend and the client. Electron is only the client. The backend communicates over the network and keeps your local database up to date. The frontend compiles that backend database into network of data that you can browse via the UI. The intention is that you work on the part you’re interested in by replacing a modular component while keeping the rest of the app the same.
Interesting, so it’s essentially Usenet without central servers and built-in spam protection a la HashCash.
Usenet started with no central servers. It didn’t even use ARPAnet. It was just a group of mainframes & minis that dialed each other up by modem and exchanged messages … literally a 1970s P2P mesh network. Even in the ‘80s, when much of it ran over P2P ARPAnet, there were still a lot of servers on dialup — I had friends at a startup in 1991 who used one of their PCs as a news server, calling some upstream server once an hour or so.
Hi all, this is @nehbit here, I’m the maintainer. Happy to answer if you have any questions!
is there anything stopping a person from encoding copyrighted material (or something much worse) as plaintext and then forcing every other node to receive it? I guess Usenet faces a similar problem, but they just don’t care/they have killfiles, right? If I’m hosting a node, can I opt out of hosting stuff I don’t like? Sorry if this is answered in the FAQ, but I couldn’t find it.
We do have some equivalent of killfiles that can be shared between users and the app supplies a default one as well.
Hosting stuff you don’t like: this is actively being worked on. Aether being a flood network makes having ‘incomplete’ nodes (i.e. everything sans the stuff you don’t want) a little challenging because the core assumption is that every node is equivalent to each other, but it’s not an impossible problem to solve.
I’ve done some thinking about similar systems. My current working hypothesis is that you can keep the digest/signature metadata of a post, but not the data itself. That way your Merkle tree or graph or whatever is intact, but stuff you don’t want is just skeletal.
You can do this, we in fact do this in Aether, it’s called the manifest and it’s the first few pages of any node’s payload. However having the manifest only makes you aware of what you have missing (i.e. saying ‘this node does not have these data’) but it does not tell you anything about where that data actually is.
The usual solution to this is to stick a DHT in front of it but DHTs fail at 30%+ attrition rates. That means, for it to work, out of 10 people that download and start the app, more than 7 will need to stay for the long term, so that DHT can reliably stick indexing data into them. That is a big ask, and it is not enough resilience for a P2P network that purports to ‘just work’, and not ask its users of making sacrifices because it’s P2P.
A while ago I checked out the docs of the Mim protocol, which Aether uses. Are there any other applications that you know of that are using Mim?
One thing I noticed is that, like SSB did with Node’s
Json.stringify, Mim relies on the output of Go’sjson.Marshalto compute and verify fingerprints and Proof of Work.I’d recommend that you introduce some canonicalization step in the protocol before it causes any headaches in the future. All attempts at building SSB clients had a really hard time w.r.t this (including my own, I had to fork a json library and modify it to become compatible with Node’s). SSB is in the process of transitioning to a new feed format that uses CBOR instead of Json, which supports a canonical ordering.
A couple of suggestions:
1). Add source code to the download list, as an archive and as a link to some git repo. Right now it’s rather unintuitive to find where the source code lives.
2). Add a users guide that is easily visible and show people how to elect, filter, vote, block, delete, etc. from the js client since, again, it’s rather unintuitive how to do it.
3). If possible post a repo of the website so people can send you UX improvements without needing to email and asking for the source code.
“mostly works” is a funny choice of words, given that the app uses proof of work to prevent spamming.