Giles TurnbullI think we need more self-hosted personal publishing tools that aren't Wordpress and don't require use of a terminal to set up. A bit of a rant: https://gilest.org/indie-easy.html
Not a Spring Onion@gilest We still treat servers like something that the user/buyer will "administer" somehow.
Something like a "smartphone moment" for VPS is still missing:
App store, simple installation and removal of said "apps", automatic updates and configuration dialogs that speak the language of the user instead of indulging in technical details.
LisPi@wakame @gilest You're not going to get that due to a number of reasons including but not limited to a lack of standardization other than the "cloud" stuff (which is overpriced).
I'd argue you *shouldn't* get that though, because we really should be moving away from endpoint-centric low-latency networking uses. For static content, it really should all be content-addressed and distributed/replicated.
At which point you *can* have something that's just an app. Or a number of interoperating apps contributing to a mesh.
(This is part of what Veilid is intended to facilitate. IPFS is a clearnet-centric example of the concept at work.)
I'd argue you *shouldn't* get that though, because we really should be moving away from endpoint-centric low-latency networking uses. For static content, it really should all be content-addressed and distributed/replicated.
At which point you *can* have something that's just an app. Or a number of interoperating apps contributing to a mesh.
(This is part of what Veilid is intended to facilitate. IPFS is a clearnet-centric example of the concept at work.)
@wakame @gilest File transfer could be done with something like magic-wormhole, there really just needs to be a user-friendly UI (problem is that it's a synchronous-use program).
Something like NNCP + syncthing for uninteractive multiple-retry would also be an option (based #AsynchronousCommunication).
(Supporting Veilid would be useful for all of those, since it takes care of the TURN-style & relay shenanigans necessary for NAT traversal and other similar annoyances.)
The homepage/blog can just be content-addressed, but it'd need to be in the Freenet/dat way rather than IPFS: not just addressing the content but incorporating an encryption key so that various caches along the path that do not have the capability/link for the decrypted file can't decrypt it. (Yes, all of those support mutable/updatable documents.)
(I'm working off the notion private = restricted access, otherwise encrypting the document is completely unnecessary.)
Calendar/Email can also be handled with NNCP over Veilid. Calendar more specifically could also be handled with a mutation capability for an encrypted content-addressed document (which I suppose makes it more a reference to another document then but whatever, precedents already exist as I mentioned prior).
Something like NNCP + syncthing for uninteractive multiple-retry would also be an option (based #AsynchronousCommunication).
(Supporting Veilid would be useful for all of those, since it takes care of the TURN-style & relay shenanigans necessary for NAT traversal and other similar annoyances.)
The homepage/blog can just be content-addressed, but it'd need to be in the Freenet/dat way rather than IPFS: not just addressing the content but incorporating an encryption key so that various caches along the path that do not have the capability/link for the decrypted file can't decrypt it. (Yes, all of those support mutable/updatable documents.)
(I'm working off the notion private = restricted access, otherwise encrypting the document is completely unnecessary.)
Calendar/Email can also be handled with NNCP over Veilid. Calendar more specifically could also be handled with a mutation capability for an encrypted content-addressed document (which I suppose makes it more a reference to another document then but whatever, precedents already exist as I mentioned prior).
@wakame @gilest You don't *need* an always-on connection (you won't meaningfully receive your mail offline anyway and you should *never* trust any IMAP host you don't make a local synchronized backup cache of, they can lose your files and they can ban you on a whim too).
Having a server ties you to infrastructure that largely shouldn't be trusted nor required.
Your home can burn down from an electrical fault or the neighbor having never learned how to cook with oil properly. If you perish in such a scenario, then sure it doesn't matter because you won't need that server anymore. But odds are you won't. You might not even be home when it happens.
You really only need occasional rendezvous of /some/ peers for NNCP to work. If you use some syncthing spool for it, it can work over local bluetooth or WLAN, and peers can be used as relays for one-another.
(Or indeed NNCP can literally work over snailmail, as a transparent extension of the spool mechanism. It's quite versatile.)
Having a server ties you to infrastructure that largely shouldn't be trusted nor required.
Your home can burn down from an electrical fault or the neighbor having never learned how to cook with oil properly. If you perish in such a scenario, then sure it doesn't matter because you won't need that server anymore. But odds are you won't. You might not even be home when it happens.
You really only need occasional rendezvous of /some/ peers for NNCP to work. If you use some syncthing spool for it, it can work over local bluetooth or WLAN, and peers can be used as relays for one-another.
(Or indeed NNCP can literally work over snailmail, as a transparent extension of the spool mechanism. It's quite versatile.)
@gilest @wakame Essentially what I'm saying is that all the parts necessary to do the job already exist in some form.
All that remains is for the tedious work of assembling in them in a user-friendly package (and in some cases refactoring or reimplementing it to remove some baked-in assumptions of the current implementations) and covering user scenarios.
All that remains is for the tedious work of assembling in them in a user-friendly package (and in some cases refactoring or reimplementing it to remove some baked-in assumptions of the current implementations) and covering user scenarios.
@wakame @gilest Actually, I reconsidered the "house fire" scenario. No need for it. We had days long power outages this year in various parts of Canada. Some because of the forest fires, which it seems will become routine because of some idiotic choices we allowed logging companies to make in reforesting and because of climate crisis reasons.
Recharging your phone from a small generator, power bank, or a car 12V->USB 5V adapter and using it to keep communicating is a lot easier and cheaper than ensuring 24/7 uptime for your raspberry server for the length of the outage.
Recharging your phone from a small generator, power bank, or a car 12V->USB 5V adapter and using it to keep communicating is a lot easier and cheaper than ensuring 24/7 uptime for your raspberry server for the length of the outage.
I would argue that until a time when your proposed solution will be realized, servers will still play an important role for... most things.
It feels as if we are talking about different time spans, principles vs. practicality and so on.
And maybe we use different definitions of what a "server" is.
For example, even in not-smart homes, you will likely have some mechanism for heating. For providing warm water. Maybe an alarm system.
It might be useful to have these systems connected to something.
Or consider your average doctor, super market or kindergarden. If you can even get them to update their opening times online, they will likely do so in the currently existing systems.
So in the near term, there is a big, gaping hole in need for a practical solution.
@wakame @gilest > I would argue that until a time when your proposed solution will be realized, servers will still play an important role for... most things.
Unfortunately, yes.
> It might be useful to have these systems connected to something.
Outside of read-only diagnostics, anything like domotic controls opens up holes for grifting as the average person cannot be trusted to keep such systems secure (and indeed most mobile phones people can afford aren't secure themselves).
Through modulating power to a hot water tank, for example, it would be feasible to encourage harmful bacterial growth in it without it being immediately obvious to the user.
> Or consider your average doctor, super market or kindergarden. If you can even get them to update their opening
times online, they will likely do so in the currently existing systems.
Some of them yes, doctors will just not update ever because digitalization of the medical system is lagging three decades back even though all the necessary tools and technologies exist.
> So in the near term, there is a big, gaping hole in need for a practical solution.
True.
Unfortunately, yes.
> It might be useful to have these systems connected to something.
Outside of read-only diagnostics, anything like domotic controls opens up holes for grifting as the average person cannot be trusted to keep such systems secure (and indeed most mobile phones people can afford aren't secure themselves).
Through modulating power to a hot water tank, for example, it would be feasible to encourage harmful bacterial growth in it without it being immediately obvious to the user.
> Or consider your average doctor, super market or kindergarden. If you can even get them to update their opening
times online, they will likely do so in the currently existing systems.
Some of them yes, doctors will just not update ever because digitalization of the medical system is lagging three decades back even though all the necessary tools and technologies exist.
> So in the near term, there is a big, gaping hole in need for a practical solution.
True.
Outside of read-only diagnostics, anything like domotic controls opens up holes [..]
Definitely. I think there are (generally) applications for e.g. hardware devices that are "not full computers".
A sensor or sending device that has barely enough power to do its job likely doesn't have an operating system or libraries with lots of hidden/unused functions.
A few years back, I was working on a project that used cameras to detect gestures.
Obvious concern: People didn't want to be filmed.
My then regrettably not implemented solution: Airgapping the whole gesture recognition and LED/photosensor pairs to have enough bandwidth for our 5-10 different gestures, but not to send images or video.
(With the added benefit that you could show a person how the communication worked by opening a box.)
trystimuli@lispi314 @gilest @wakame So I'm currently working a storage+sync layer akin to freenet/git/pubsub. First application is a distributed file system, currently working on a btree library for it. Eventually it'll cover all the aforementioned use cases except unsolicited email.
I'll still want servers, for backups and time-shifting, but why should I need connectivity to a server for my change to a calendar to show up on my friend's device next to me if we're taking a walk and making plans?
@trystimuli @wakame @gilest At that point, the server is more of a caching relay, which I'm not arguing shouldn't exist at all (there are cases where it can be practical to a have a stable node for rendezvous), but that it shouldn't be a privileged or irreplaceable role.
Your system seems like it lends itself to that vision.
Your system seems like it lends itself to that vision.