You are vastly underestimating the youths current addiction to social media. Take it away and you will see some rapid pursuit of novelty.

I have suggested a couple of times now that ActivityPub should implement an encryption layer for user authentication of requests and pings. It already has a system for instances vauching for each other. The situation is that users of "walled garden" instances in ActivityPub lack means of interfacing with public facing instances that doesnt leave the network open for scraping. I believe a pivot towards default registered users only content service built on encrypted handshakes, with the ability for servers to opt-in to serving content to unregistered users would make the whole network much more robust and less dependent on third party contingencies like CloudFlare.

Then again, maybe I should just be looking for a different network, I'm sure there are services in the blockchain/cryptosphere that take that approach, I just would rather participate in a network built on commons rather than financialization at it's core. Where is the protocol doing both hardened network and distributed volunteer instances?

Isn't this thread about sinks?

single handles are all well and good, but I'd prefer a hot knob, a cold knob, and a flow knob. I've never been clear why this isn't done, I suppose its probably cost. Maybe there is some wear and tare reason?

Fediseer seems like a good solution, essentially a whitelist vouch system with touching at second hand.

Regarding the media hosting, again it seems like something that could rely on a method of identifying the user request directly with their user account before responding to the request. Cookies could be an option for this, though they are falling out of favor. Alternately, and more securely, it could be a cryptographic handshake where the user's home instance and the instance hosting the post generate a public key using their two private keys for the user, and the user provides the public key when making pull requests from the federated instance. The keys could be batch generated when an instance first federates content with another and then assigned to user accounts the first time the user makes a pull request through a link from their home instance to the federated instance.

Secure Scuttlebutt Protocol already deved the encryption methodology that could be cross applied for a lot of this: https://ssbc.github.io/scuttlebutt-protocol-guide/ though I am of course not suggesting SSP be adopted whole cloth, and there are a bunch of other OS projects with encryption that could be used. This is just the one that comes to mind.

(edit: also I am in favor of finding methodologies that work whether CloudFlare is used by the instance or not, obviously CloudFlare has advantages but as we have seen also is a vulnerability of the network.)

awesome! glad to see it.

hahahaha, what a mess.

the downvotes are for "neat"

Hmmm... let's find the best ways to both make money from this program and yet somehow the targeted individuals manage not to get detained.

on the flip side, a wifi 7 access point, firewall, NAS, server, and network switch in this performance range are going to cost a bit more by my reckoning. I do see your point about repairability and reliability, one power supply for all of it could be problematic.

As far as security, couldn't most of what you mentioned be effectively achieved in software if implemented correctly? Looking at the company website, that seems to be their primary focus area.

nice, thanks for the post

Thanks, try now