5
6
Fork
You've already forked callisto
1
A project to put protocol first, initially in pursuit of a social forum focused on link sharing.
  • Common Lisp 90.9%
  • Makefile 9.1%
2023年12月12日 18:23:41 -05:00
callisto-network reference the event-base storage. 2023年11月16日 11:03:56 -05:00
.gitignore update gitignore to ignore build artefacts. 2023年06月13日 15:17:17 -04:00
app-utils.lisp super soft project skeleton. 2023年06月13日 14:50:38 -04:00
callisto.asd reorganize the system to define callisto package in dedicated file. 2023年06月22日 11:18:30 -04:00
callisto.lisp System to contain networking code. Rough-in of socket server. 2023年08月09日 13:37:34 -04:00
LICENSE but format it for a terminal. 2023年07月21日 10:21:15 -04:00
Makefile super soft project skeleton. 2023年06月13日 14:50:38 -04:00
package.lisp reorganize the system to define callisto package in dedicated file. 2023年06月22日 11:18:30 -04:00
README.org descriptive update. 2023年12月12日 18:23:41 -05:00

Callisto, Introduction

This is a lisp machine for network protocols. Initially in persuit of a social forum focused on link sharing.

Rationale

The idea is that Reddit, Twitter, Slashdot, and image boards like 4chan are all the same application, and this application has already been defined in the IETF protocols: Network News RFC 1036, and advanced in the subsequent RFC 5536 which obsoletes 1036. Given the current furor over Reddit's particularly eggregious policy change around API access and the resulting destruction of the ecosystem of third party applications, and in response to a lengthy discussion in the #systemcrafters-hacking IRC channel on libera.chat (matrix space also available: #systemcrafters-hacking:matrix.org ), it was suggested we try to write a system as proof of the validity of this thesis.

In the past decade, it seems that there has been a collective storm of amnesia, as startups and free projects alike rush to implement some IETF RFC adding only 'but on the web'. I aim to define a modular protocol server which can support an arbitrary number of network protocols as a network daemon. Our POC in this endeavour will be to build an NNTP-like protocol daemon which gateways to IPFS storage. The content held in this system can be consumed by arbitrary clients; a web application presenting reddit-like services would be just one of many potential clients, although it is likely that Gnus for Emacs will be the first one.

For those of you who were not alive or present for the early public internet, this is a good small documentary on Usenet.

What Should be Here

The protocols contained in this system will ideally reflect the agreed specifications for internet services, as defined by the Internet Engineering Task Force, but not exclusively. Because the scope of this system is trained upon the service of a single user which it serves, and because that user can be anything from a large organisation, to an individual who just wants to post something on the internet and talk to their friends, it is likely that our little protocol reactor will grow many appendages which calculate about the data specific to the user it serves.

In the persuit of our first integrated service, which is an internet discussion forum, I am going to closely recapitulate the IETF network news specification, with modifications to permit article storage in the InterPlanetaryFileSystem. This change will break the specification in several places, most specifically where V2 calls for whole articles (headers and body) to be returned in response to various commands.If we detect the presence of a V2 reading client, it should be possible to switch modes for the session so that articles are reified in situ and sent down the wire as expected by any NNTP client. This will, for example, allow the interactive posting to be undertaken outside the web with something like Emacs' GNUS client.

On the way to this discussion system we will need several support services, so at the conclusion of the discussion component we're going to have:

  1. Webserver and application framework
  2. SQL Database
  3. Kademlia
  4. Identity (Keyoxide? UCAN? Yes?)
  5. Public Key server
  6. IPFS (possibly via FUSE, initially)
  7. NNTP server

The next requirement will be to do something about email. Email has become too difficult to send reliably outside the systems of one of the remaining internet colossi. Wave has failed twice, now, but I think the idea is good. I'd like to take the spec of the Apache Wave Protocol and integrate a wave server within Callisto. If there's one message to be taken from this section, it should be that we shouldn't be afraid to mine the past for good ideas that were killed by Worse is Better, particularly since we have access to Common Lisp, which I have found to be a force amplifier. Of course, milage varies, and there's no substitute for good taste.

Build environment/Dependencies

All of these components, save Quicklisp should be available from the package manager in your operating system. This system has been built and tested on Arch and Debian Linux, as well as FreeBSD, although I don't plan to support FreeBSD as a deployment system.

Note: The Makefile presupposes the presence of Quicklisp (QL). Standard system packages for the requisite dependencies don't fully install Quicklisp functionality and for it to be present during make, you will have to follow the Quicklisp installation instructions present at the provided http link to the QL project homepage.