Kris described hachyderm's infrastructure operating in her basement on the Oxide and Friends podcast in mid-November. Kudos to her for being able to keep it going there so long!
As someone who'd hoped to start an industry-focused instance, I found Kris' Medium articles about Hachyderm's growth really interesting: https://medium.com/@kris-nova
The latest post, "Yelping: Action Through Criticism", includes links to additional Hachyderm-related content near the top, then talks about they handle an obnoxious online behavior they've experienced because of the recent popularity of Hachyderm.
As a kid I remember ordering free MSP430 samples from TI (in DIP format)
SOIC would have been completely inaccessible for me as I mostly relied on breadboards and a radio shack soldering iron with a half-corroded tip that would probably be better suited for plumbing than placing SOICs
This bears repeating every once in a while: surface-mount soldering is not very hard. It's perhaps harder than through-hole, since you don't get the benefit of having the component held mechanically, but not by a lot.
The actual soldering with surface-mount stuff does not mean you have to be like an industrial robot in your precision and gently apply heat to each tiny tiny leg, while also getting the solder in there just in time, all the while holding your breath so you don't blow things away. Not at all.
Surface-mount soldering can be done using way "uglier" techniques than through-hole, where you basically flood the component's legs with solder, heat it enough for it to melt and flow, and then remove the excess. Thanks to the magic of surface tension (and, if you have it, extra flux) the solder will flow to where you want it, all on its own. This kind of technique probably wouldn't cut it for production, where consistency and quality of course are important, but for hobby use it's fine!
There are plenty of YouTube videos showing this off, it can be really really easy. Please don't fear surface-mount soldering. Grab (the cool side of) your iron and join the fun!
As an adult with disposable income surface mount is easy, I have great soldering irons and I order PCBs all the time (used to make them too but it's gotten cheap enough that it's not worth the hassle)
But for a 15 year old with no budget and limited tooling (even flux would have been a luxury), being able to order off a sample form and get something that just worked was invaluable.
My original comment related to Andrew saying he wasn't going to create his own, not about whether or not other Django based ActivityPub projects existed. There are likely others beyond Andrew's and Marnanel's.
Before you go to the trouble of writing your own software, consider using one that's already been written. There are many[0] out there already besides Mastodon.
Where receive.php is openly accessible and send.php is protected by a password.
The endpoints are surely called differently than receive.php and send.php. But this is how I would hope ActivityPub works in principle.
Of course, this would be very bare. To read, I would have to read the raw log of ActivityPub messages and to post, I would have to manualy put together an ActivityPub message.
But I would be in the Fediverse and could add more convenience functionality later.
- send requests with proper 'HTTP Signatures' (many AP nodes have strict enforcement here)
- which requires you to have an actor with an attached signing pubkey
- so you have to host the LD-JSON actor descriptor on another endpoint
- actors MUST have an attached inbox & outbox, your receive endpoint will need to sit at your actor's inbox (on POST). both of these are OrderedCollections of Activities
- and in order to be properly interoperable you will probably need to maintain follow relations & write an endpoint which can ACK/NAK follows, etc etc
If admin of serverA decides to add serverB to the servers_i_talk_to array, they also ask serverB to give them a public key and from then on serverA only accepts messages from serverB if they are signed with the corresponding private key?
Is that so that serverB can change its IP without interrupting the communication with serverA?
The fediverse is (generally) an open federation, not a closed one like you're describing. There is no manually-curated list of instances that you federate with.
I would expect "Open Federation" does not mean you need to talk to every instance out there directly. But that it works like a web where messages are routed around. I could be wrong. But I would expect the "servers_i_talk_to" array is what the instances output at the "peers" endpoint:
There's not really any routing, but you don't need to send posts to every instance, just every instance that has users following your instance's users.
HTTP signatures ensure that you can't send a message and spoof the user/instance that it's coming from. Think of it like DKIM for AP.
They commonly include the specific actor who is interacting with the network (via the instance), so we can also achieve correct-side enforcement of blocks.
Sure an actor is basically a user, there's usually an "instance actor" though too that does some other things but I don't think having one is required. Every actor has a private key but it's kept on the server, it's basically an implementation detail.
Strange that users have private keys. Is that kinda forward-looking, so that at some point those keys could be moved to the users themselves? So they can keep their identity, even if the owner of their instance becomes malicious?
The private key is used in HTTP Signatures for authentication. The signature does not cover the body of the http request and is not stored or published. The http post contains an http headers that signs just a few other header fields. The signature is only valid for a short time.
I used to use Cloudflare's API to do this, but then we changed ISPs and now are behind CGNAT, so we don't even have a public IP. To publicly expose my web server, I created a Cloudflared tunnel, and have our DNS (which is also hosted at Cloudfare) point to the tunnel. It works quite well, and adds some security because we're no longer visible to attackers using IP address scans.
Online specs says T610 idles at ~12W and full load at ~20W [1], but I haven't personally measure it myself. I'll try measuring it myself when I got a chance later.
If it's really idle at 12W, it means the electricity cost is about $12/year. For comparison, I think pi4 averages at ~5W.
Did you try forcing yourself to sleep on your side? I found if I roll onto my back while I sleep I frequently would either snore or stop breathing to the point where it would cause me to wake up.
To keep from sleeping on my back, I now put a foam roller under the back of my shirt before I go to bed. It's eliminated my snoring and help me sleep much better. Other people pin a tennis ball to the back of their shirt for the same reason.
I bring this up because I think many people are prescribed a CPAP machine to solve their sleep problems when positional therapy would be a more effective, less expensive solution.[1]
In my case, I have tried this and it didn’t work. Unfortunately I have what is known as a “floppy epiglottis”, which is what is preventing me from breathing.
With the CPAP machine I am definitely getting a better night’s sleep.
How does Phorge/Phabricator compare to other code management tools like Gitea or GitLab in terms of resource requirements? Can it, e.g., run along side other apps on a single-board computer, or does it take more system resources than this?