You are reading content from Scuttlebutt
Feed of @cft
@cft
Re: %dlRtBNmQD

@andrestaltz wrote:

I don’t understand how you think this is a hack. It’s very similar to replication over LAN, so it’s very scuttlebutty.

(Please read the following with the assumption that I try to push my argument as pure as possible.)

I would say that rooms and LANs are "very internetty", regrettably, not scuttlebutty. Location to me is not important, it's a misleading and non-SSB concept.

The current situation (dependency on IP, host-centricity of the transport) is far from satisfactory. The point that I try to make is to avoid thinking in terms of connections, links, but also LAN forwarding from one MAC address to the other. The marvel of SSB is that it looks at content flowing everywhere as soon and as far as it can, it couldn't care less about location. The current SHS tunnels, etc are temporary crutches. Agreed, we have to use them right now, but the sooner we can replace them the better, the less we depend on them the better. Increasing that contact surface is what I'm concerned about.

Technically, the more content we store inside the net, the better (because then it can travel farther, be fetched by more destinations, can be blocked less, has higher availability), while your rooms seem to work in the opposite direction.

It's friendly how I mean it: I follow you, but not the room idea.

@cft
Wrote something private
@cft
Wrote something private
@cft
Wrote something private
@cft
Wrote something private
@cft
Re: %dlRtBNmQD

I see the pragmatic argument for the room concept, but I would call it a hack in the sense that it pulls SSB away from its core property, namely log replication. Worse, it could turn out to work against what SSB wants to achieve, namely resilient, unstoppable flow of information. How easy it is to track IP numbers, or get a whole country off the Internet. Therefore I would simply say no to SSB features that depend on or bow to some property of the current Internet.

By introducing special tunnels between log-keeping places, you invest time and programming effort in TCP-style connection-oriented tech where already now (=in this thread) concepts like ephemeral IM are brought up. If ephemeral IM is a desire, then let's better talk about ephemeral logs that can quickly be spawned and later garbage collected. But don't abandon the in-network memory model of the SSB forwarding fabric. As you point out, delay tolerance and off-line capability are sacrificed for this hack.

@cft
Wrote something private
@cft
Wrote something private
@cft
Wrote something private
@cft
Wrote something private

Show whole feed
Join Scuttlebutt now