Re: A native internet protocol for social media

On 20 Apr 2023, at 17:56, Bob Wyman wrote:

> Marcus wrote:
>> Websockets don't scale, do they? Imagine 10k 
>> subscribers/subscriptions
>> from 10k instances. That means 10k persistent connections/websockets,
>> doesn't it?
> The reality is that Websockets do, in fact, scale much more than many 
> would
> assume.

What's the argument here? What many may assume? Please.

> A little bit of Googling

So please do it and present the results here.

> turns up many examples of people who have
> tested Websocket scaling and found that even personal laptops are 
> capable
> of handling 100's of thousands of simultaneous connections.

Again, 'someone wrote on the internet' isn't an argument.

> The
> introduction of horizontal scaling, load balancers, or exploitation of
> various cloud Websocket services,

That's what I mean with heavy, enterprisy deployments. No participant 
wants to do that and so it manifests the divide between dictating 
operators and dependant users. Not my vision.

> can make large numbers of Websockets
> connections reasonably easy to support and less expensive than 
> creating and
> tearing down individual short-lived connections. The issue isn't 
> really the
> number of connections, but rather the volume of traffic generated in
> serving those connections.

numbers please.

>>  And what is the use case other than real-time? Which shouldn't be a
>> requirement.
> Every ActivityPub client that I've used attempts to provide at least 
> near
> real-time response. I typically get notification of responses, boosts,
> likes, etc. within seconds of when they are made. So, although 
> real-time
> may not be a stated requirement, it is certainly a service-level that 
> many
> clients and servicers attempt to achieve.

We really have to talk about dark patterns, healthy patterns and stress. 
Communication is the end, technology the means. The latter has to serve 
and fit the former. There is no shortage of real-time choices in terms 
of communication, is it? Real-time isn't the sweet spot of ActivityPub 

> It would be reasonable to
> consider specification modifications that make it easier for such
> service-levels to be achieved.

Consider: yes, pay a price: no. And then explicitly exclude.

> Also, we should consider that there is
> nearly continuous transfer of information between many servers --
> particularly when servers are exchanging information with the larger
> instances. A protocol option that reduces the need for continuous
> re-establishment of connections would reduce servers' resource 
> requirements.

Designing for huge nodes' needs doesn't align with the 'fedi' nor the 
'verse' if conflicts with small nodes' needs. And complexity is against 
small nodes.

What is our shared vision?


Received on Friday, 21 April 2023 07:27:34 UTC