So the hardware is pretty much done. Or at least 'done enough', so it's time to build some software. The basic idea is simple: a web portal people can sign up to, post public messages in threads (aka a forum) and upload/post files.

How hard can it be?

If I were to be developing this normally, with AWS cognito for user sign in, with sqlalchemy, react+node, jwt's and all other good modern tech, probably not too bad! (Heck, at work the system we've build offers this functionality accidentally). But thus is a learning project! So it's all in python, with python's standard library and nothing else.

So let's write a web server. We need to listen on port 80, and parse an HTTP request. Fortunately this is actually pretty simple because it was invented back in the dawn of time and is well documented (and I'll even do it non-blocking. Ooohhhh, green threads... trendy). Parsing the method, URL and headers is a tiny amount of code. Generating responses is equally trivial. And ... tada! We can serve static files such as this mock-up:

As a bonus, I now know about 302 redirects. Large file support (range requests) and post content is waiting until I need to implement it.

But serving static files isn't what we want to do. We want users to be able to log in. This means we need:

1) A database (to store passwords, posts etc). Fortunately pythons stdlib has sqlite3, which should be fine for our use case.

 2) A method of encrypting passwords. Owasp has a great article on this: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html that outlines different methods and why we need to salt passwords. While python's stdlib doesn't have Argon2id, it does have hashlib.scrypt, so we should be good.

3) A secure connection between a client and our server. Uhm, erm. This is hard. I want it to be an open wifi network so strangers can connect. This means the transport layer is unsecured. HTTPS would solve this, but we'd need to have a self-signed certificate and this makes big warnings on most browsers. I'm leaving this as an open problem for now. We may just end up transmitting passwords in the clear ..... to anyone wifi sniffing. There are solutions for this (Diffie–Hellman key exchange) but the level of effort required is high.

4) Session management. After a user has sent their username/password combo, we need a cookie or toke or something to send with each request. If I were to use the modern approach (jwt's) I would need to be using a single page app and a bunch of JS, so I'm going to fall back to cookies, which browsers automatically send. The DB will then have to store a session -> user mapping along with an expiry date.

Oh yeah and I'm going old-school with server-side rendering. If I only have one programming language (python) I think it will be easier/quicker/smaller.

So anyway, on with the SQL writing!

------

What is the difference between a social network and an online forum?

I'm not actually too sure, but I think it has to do with data availability. On a forum, most posts are public, so everyone owns the data equally. On a social network the data is private to select users, so it seems strange when the company running the network 'steals' it. Oh yeah, and "..... news feeds ..... self reinforcing biases ..... Artificial Intelligence ...... evil"