One thing that I found really fun and very educational was to find a protocol or format I found cool (something like XMPP, WebDAV, SSH, gzip, etc) and try to implement it in a place that wasn’t immediately obvious how (like, if you’re trying to learn Go, maybe don’t pick WebDAV, cause it’s already implemented in the standard library). I like to print out the RFCs or specs and put them in a binder. Then I read through and highlight important bits and put little sticky flags on the page. Then as I implement it, I’ll reference that printout.
It’s an incredible feeling when you get to the point that your software is talking to someone else’s software and it’s all working. And it really teaches you how the software you use every day really works under the hood.
Btw, I wouldn’t recommend the ActivityPub protocol. Even though it’s really useful and really powerful, I don’t consider it to be written very well or novice friendly. There are a lot of places where it is either ambiguous or just flat out contradicts itself. If you find a protocol like that, it can make you want to pull your hair out.
Ah yes! That is a great trick that kept me going doing software dev professionally.
Instead of trying to get the system I was working with to interact correctly with some shit enterprise system, I would find common protocols (or related protocols) and implement that well.
Then I would discover more specifically where the shit enterprise system was behaving badly, and point to something politically neutral (like an IETF RFC) to help get us out of a rut.
It made debugging so much easier.
Those specifications and open-source implementations have had much more engineering talent put in them than what I was usually dealing with.
ActivityPub was basically written to support everything any social network could do, so there aren’t really well defined ways to do anything. An example is that there’s no standard markup language for notes. They can be text, HTML, markdown, whatever. It was the first W3C spec I read through, and I’m used to reading IETF specs. Maybe I’m just not used to how W3C does things, but the spec left me with a lot of open questions. It’s ambiguous about how things work in a number of areas. Especially about what things are allowed in other things. There are parts where you get the impression that something can only be an array, but then later it’ll show an example where it’s a single item not inside an array.
It was also supposed to be both a server and client protocol, so that any server should be able to talk to any client, but they don’t cover at all how to actually authenticate the client to the server. Oauth is the standard, but there’s no standard way to add your client to any given ActivityPub server. So you just have to code for whatever server you want to talk to.
So essentially what I mean is that you can’t build functioning software just by reading the spec. You must look at existing implementations to see what they do before you have any hope of working with them. To me, that means ActivityPub is an incomplete spec. I hope they remedy that with an update.
I’ve heard of Nostr. It looks really great on paper, but in reality, it’s filled with spam and cryptobros. It’s not moderatable, which makes it a target for spam and scams.
I’d recommend something like SFTP or WebDAV. They’re incredibly well defined and very useful to have an implementation of your own. I’ve written my own WebDAV server called Nephele, and it was really fun once I got it communicating with other software. Now I use it on my own server and I back up all my computers to it.
A long time ago I wrote an XMPP client which was really fun. I wouldn’t say it’s as useful as the others because not many people are on it, but it’s a great protocol.
I would recommend email for this. It’s a text-based protocol and the original RFCs 821/822 are pretty straight-forward. There are some additional rabbit holes related to content encoding, but if one can implement a simple MTA, a huge amount of the magic of the internet becomes accessible.
I would not recommend trying to build a “production grade” MTA, as there is a lot of minutia to get right, and it’s easy to screw up.
One thing that I found really fun and very educational was to find a protocol or format I found cool (something like XMPP, WebDAV, SSH, gzip, etc) and try to implement it in a place that wasn’t immediately obvious how (like, if you’re trying to learn Go, maybe don’t pick WebDAV, cause it’s already implemented in the standard library). I like to print out the RFCs or specs and put them in a binder. Then I read through and highlight important bits and put little sticky flags on the page. Then as I implement it, I’ll reference that printout.
It’s an incredible feeling when you get to the point that your software is talking to someone else’s software and it’s all working. And it really teaches you how the software you use every day really works under the hood.
Btw, I wouldn’t recommend the ActivityPub protocol. Even though it’s really useful and really powerful, I don’t consider it to be written very well or novice friendly. There are a lot of places where it is either ambiguous or just flat out contradicts itself. If you find a protocol like that, it can make you want to pull your hair out.
Ah yes! That is a great trick that kept me going doing software dev professionally.
Instead of trying to get the system I was working with to interact correctly with some shit enterprise system, I would find common protocols (or related protocols) and implement that well. Then I would discover more specifically where the shit enterprise system was behaving badly, and point to something politically neutral (like an IETF RFC) to help get us out of a rut.
It made debugging so much easier. Those specifications and open-source implementations have had much more engineering talent put in them than what I was usually dealing with.
You seem knowledgeable, could you go a bit more into detail why you wouldn’t recommend activityPub?
Did you hear of nostr?
What protocol do you recommend and why?
If you don’t mind me asking.
ActivityPub was basically written to support everything any social network could do, so there aren’t really well defined ways to do anything. An example is that there’s no standard markup language for notes. They can be text, HTML, markdown, whatever. It was the first W3C spec I read through, and I’m used to reading IETF specs. Maybe I’m just not used to how W3C does things, but the spec left me with a lot of open questions. It’s ambiguous about how things work in a number of areas. Especially about what things are allowed in other things. There are parts where you get the impression that something can only be an array, but then later it’ll show an example where it’s a single item not inside an array.
It was also supposed to be both a server and client protocol, so that any server should be able to talk to any client, but they don’t cover at all how to actually authenticate the client to the server. Oauth is the standard, but there’s no standard way to add your client to any given ActivityPub server. So you just have to code for whatever server you want to talk to.
So essentially what I mean is that you can’t build functioning software just by reading the spec. You must look at existing implementations to see what they do before you have any hope of working with them. To me, that means ActivityPub is an incomplete spec. I hope they remedy that with an update.
I’ve heard of Nostr. It looks really great on paper, but in reality, it’s filled with spam and cryptobros. It’s not moderatable, which makes it a target for spam and scams.
I’d recommend something like SFTP or WebDAV. They’re incredibly well defined and very useful to have an implementation of your own. I’ve written my own WebDAV server called Nephele, and it was really fun once I got it communicating with other software. Now I use it on my own server and I back up all my computers to it.
A long time ago I wrote an XMPP client which was really fun. I wouldn’t say it’s as useful as the others because not many people are on it, but it’s a great protocol.
I would recommend email for this. It’s a text-based protocol and the original RFCs 821/822 are pretty straight-forward. There are some additional rabbit holes related to content encoding, but if one can implement a simple MTA, a huge amount of the magic of the internet becomes accessible.
I would not recommend trying to build a “production grade” MTA, as there is a lot of minutia to get right, and it’s easy to screw up.