System Recommendations
Intel Pentium® processor-based system, 60 MHz or higher
Windows* 95 or Windows NT* operating system
Half-duplex sound card with speakers or headset
Microphone for voice input
Client: Modem, 28.8 Kbps or faster
Server: ISDN or higher connection to the Internet
An Internet service provider that supports TCP/IP*
"real-time, multi-party audio chat over the Internet" was possible 24 years ago. Meanwhile, on a two-year-old computer, I still have frequent trouble getting Teams audio chats to work without stuttering and breaking up on a 50Mbps connection...
A lot of things are possible for very long times, but for some reasons that I cannot fathom, we decide to abandon nicely working things for flashy, less capable and closed systems.
I don’t see what closed systems have to do with it.
The big difference now is that someone with no computer experience can tap a touch screen and chat for hours using a device the size of a candybar wirelessly from the back of an elephant in rural south east asia.
Ease of use and decent software performance optimizations shouldn't be mutually exclusive. Just because we have touchscreen now doesn't excuse the shit show that some modern software has become.
I shouldn't need Apple M1 levels of performance just to browse the reddit frontend without issues.
> I don’t see what closed systems have to do with it.
That someone would have been using an equally easy to use user interface running on XMPP/IRC or any other open/interoperable and lightweight protocol with official extensions built by executing RFC mechanisms all had for years.
Instead we're using nice UI's running closed ecosystems on closed protocols and no optimizations since my smartphone's battery life, network limits and hardware capabilities be damned. Hardware is cheap, network is reliable. Let's move fast and break things until Hardware buckles and network clogs.
Internet was a network of networks. Now it's a garden of walled gardens.
> That someone would have been using an equally easy to use user interface running on XMPP/IRC or any other open/interoperable and lightweight protocol with official extensions built by executing RFC mechanisms all had for years.
Possibly so, but what relevance does this have?
We still can do all this with open protocols if we want to.
When I read comments like yours, I read them as a repudiation of pop-culture.
Instead of re-inventing proverbial wheels over and over, we could have done much more if we chose to improve the tools we had at that time.
> We still can do all this with open protocols if we want to.
Yet, we don't. Instead allow web to be centralized and fragmented. At the same time we're trying to decentralize it.
> When I read comments like yours, I read them as a repudiation of pop-culture.
I don't know where you're coming from (I'm not a native English speaker, I can't completely understand what you're trying to do), but I all I can say that, I do not support wasting that much computational power by not-optimizing and/or inventing inferior things and marketing them as superior.
I arrived to this point by hands-on experience. Giving a little more thought to something you develop or just planning a little ahead goes a very very long way in terms of efficiency an performance.
> I don’t see the point in that.
You may not, and I won't judge you for that. However, I see a more capable future with less effort down the road.
> > We still can do all this with open protocols if we want to.
> Yet, we don't. Instead allow web to be centralized and fragmented. At the same time we're trying to decentralize it.
This speaks to my point about pop-culture.
When you say ‘allow’ you are implying that there is someone who could disallow this if they do chose.
There isn’t. There are just millions of programmers who weren’t active in the historical era you are comparing to, making products for consumers who also were not around then.
This is a pop-culture. It’s what happens when computers become democratized.
> I do not support wasting that much computational power by not-optimizing and/or inventing inferior things and marketing them as superior.
It doesn’t matter who ‘supports’ this or not. This is what I mean by repudiating pop-culture.
> I arrived to this point by hands-on experience. Giving a little more thought to something you develop or just planning a little ahead goes a very very long way in terms of efficiency an performance.
Again- this is true, but it’s not really clear what relevance this has.
I don’t support the construction of ugly homes that are too small or cheaply designed for people to feel good about.
What is missing in my mind is not people like you and I ‘not supporting’ things: it’s an understanding of how to make things better.
This isn't real-time multi-party audio, but delayed/queue one-at-a-time audio (description describes it as like a text chat room with audio instead of text). Real-time multi-party is much harder.
It’s easy if you change the requirements. Buffers help with stuttering but cause delays. Less sampling and more compression help with bandwidth usage but cause lower quality.
By the way, you could participate in multi party audio check from an analog phone.
> Meanwhile, on a two-year-old computer, I still have frequent trouble getting Teams audio chats to work without stuttering and breaking up on a 50Mbps connection...
The difference is that back in the day people developed software to solve problems, where as nowadays software is mostly developed to "engage" customers, lock them in or provide job security to engineers by having them rebuild the same thing every year in yet more layers of Javascript libraries and frameworks.
Depending on the number of people in the room, this could easily turn into insane waits between when you sent your message and when everyone hears it. This would probably work best in a conference call sort of situation where you have people mostly speaking one at a time rather than just a normal IRC room where there's a dozen conversations going on simultaneously.
You'd need some really great moderators for this kind of conversation. No conversation is perfectly linear - new ideas lead to forks, and a large group needs to somehow choose whether or not to take one. But if there's a queue of five folks waiting to speak, that's four opportunities for the tangent to either be taken or not taken, and exponentially many opportunities for the wrong tangent to be replied to.
It would be fun to design ways to manage the latency. I could imagine a modified push-to-talk where you hold down a key and the system gives you an audio cue to start speaking when the backlog of audio has dropped to an acceptable length. The system could also load balance speakers that way, giving people who make shorter or less frequent statements priority in the meeting.
> Internet Party Line queues each person's statements and plays them serially, which allows each person to talk without interrupting the others
This would be a game changer, for those of us who are a bit deaf / have trouble picking out multiple voices. This is harder on normal voice conferences because they're not spatial; everyone's speaking to you from the center of the stereo pan.
Omnibrain - I’m curious: you submitted this 2 - 3 days ago, yet this is a fresh submission showing “3 hours ago”. Only this post is in your submission history.
How are you able to ‘bump’ or ‘refresh’ a submission in this way?
It's too bad they don't use real HTML anchors. All FAQ index links fail if JS execution from that domain is disabled. It is a common problem with using github for documentation.
I had no hand in this. It's either what silasdavis said https://news.ycombinator.com/item?id=26927915 or someone else submitted the same ink what lead to a bumb or something else entirely.
Getting IDMOO running live again would make an interesting browser experiment. Hardest part may just be finding a downloadable archive. This is why software preservation is so hard ;)
