Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple Unix Chat

the-dam.org

Post reply on HN
Print view View original

41–50 of 175 posts

Re: Simple Unix Chat

#41

Post by onetom »

devmor wrote: post #25
wfme wrote: post #11

This is very reminiscent of the initial hn response to DropBox [0]. This is like saying that you can build a Tesla clone by attaching 3 pieces of wood together along with 4 wheels. Although it is technically cool, it misses practically all of what makes Slack so popular - UX. [0]: https://news.ycombinator.com/item?id=8863

>it misses practically all of what makes Slack so popular - UX I strongly disagree. Slack has nearly the same UX as every chat platform of the past 2-3 decades. It's a slightly change over AOL Instant Messenger. There's also a large amount of very similar software or straight-up slack clones that are not very popular at all. I would say what makes Slack so popular is how easy it is to set up and get running, both as…

there are a bunch of features in slack beyond the core chat stuff, like:

1. being connected to multiple communities and switching between them instantly

this can be of course simply replaced by connecting to different servers in a tabbed terminal and use the terminal's built-in cmd-1/2/... shortcut, which happens to be the same as in slack.

2. meta data about others, like their timezone or how to pronounce their name is quite important for distributed team work

this can be approximated by a world readable file on the chat server in every user's home, like .plan or motd files (https://github.com/ESWAT/john-carmack-plan-archive)

3. automatic idleness detection

im actually not sure how reliable is this even in slack, but in general, it can be useful, but im not sure how to solve it elegantly, when the chat runs remotely...

maybe we should just spawn a loop at the background, which gathers idleness status from the OS and uploads it when it changes, into world readable files and the remote clients can just check those file whenever they want.

4. extra status indication with automatic expiry, eg when someone is away from the keyboard, coz they are having lunch

we do use this feature often and it's a really helpful regarding when can we expect a response from someone.

again, quite simple to model this as a plain text file and we can even use emojis, to have a very similar effect to setting " lunch" on slack. ppl would need to know what's the emoji selector shortcut though... like cmd-ctrl-space on macos.

5. text search across all channels/rooms

assuming the chat is being logged into files, then a recursive (rip)grep could work to some extent, but then from the search results one might want to get back to the context of the result too.

6. threads

this complicates implementation a lot more, but we found it an obvious improvement over the single threaded IRC model of communication

7. having threads open on the side, so ppl can track 2 streams of comms at once at least

it would require starting the chat app multiple times and do some window management to see them side-by-side

now obviously all this can be done a lot simpler, but those implementations typically always lack somehow. not sure why is that...

see https://cancel.fm/ripcord/ or http://www.altme.com/what.html

the REBOL 3 programming language even had a quite full featured, text-mode chat built in: http://www.rebol.com/r3/docs/functions/chat.html !

Re: Simple Unix Chat

#42

Post by dclowd9901 »

eyelidlessness wrote: post #40
dclowd9901 wrote: post #37

Earlier quoted context omitted.

It’s disingenuous at the least and complete dickishness at the median.

It’s pretty valid disingenuity. It’s just also pretty valid to identify as such.

Did the title contain the disclaimer? I only found it after visiting the page.

Re: Simple Unix Chat

#43

Post by onetom »

what do i do after i sign up to the-dam.org ? i did not get any email after the payment and ssh-ing doesn't work either. (i just get a `Permission denied (publickey)`)

Re: Simple Unix Chat

#44

Post by kelvinjps »

kitchi wrote: post #7
eyelidlessness wrote: post #4

> suc does all that by leveraging SSH, UNIX’s access control API, and UNIX’s text-based modularity. On any fair metric, this should inflate the volume of code metric for any project (whether leveraging those APIs directly or not). It would still favor this implementation on that front, and there are still other merits to the approach besides code volume. But something does irk me about touting supposed minimalism whi…

I had a similar thought. But it also struck me that "externalising the maximalism" by using a library like the unix ssh implementation is probably the best way to go about it, since it's a widely used well tested library that implements a complex use case. In scientific programming I'd say that's the same as using a library like GSL, BLAS or even numpy. The net impact on LoC in my project is minimal, even though it c…

I think that the main difference is that unix tools are intended to work which each other. Therefore needing less line of code. As opposed on other systems.

Re: Simple Unix Chat

#45

Post by lynx23 »

spicybright wrote: post #8

In case you're passing over this because it sounds like click bait (it KIND OF is), this was actually a good read to me. It goes over a utility called "suc" (Simple Unix Chat) that implements server functionalities from Slack, Discord, etc. using a very small codebase. The novel part is it leverages existing unix tools and methodology instead of re-inventing them. - Auth is handled by SSH. - Channels are just a file…

Wait, KISS is a novelty? :-)

Re: Simple Unix Chat

#47

Post by 59nadir »

onetom wrote: post #43

what do i do after i sign up to the-dam.org ? i did not get any email after the payment and ssh-ing doesn't work either. (i just get a `Permission denied (publickey)`)

Same for me. I suspect maybe they add the public keys manually and haven't gotten around to it yet.

Re: Simple Unix Chat

#49

Post by skullt »

onetom wrote: post #41
devmor wrote: post #25

Earlier quoted context omitted.

>it misses practically all of what makes Slack so popular - UX I strongly disagree. Slack has nearly the same UX as every chat platform of the past 2-3 decades. It's a slightly change over AOL Instant Messenger. There's also a large amount of very similar software or straight-up slack clones that are not very popular at all. I would say what makes Slack so popular is how easy it is to set up and get running, both as…

there are a bunch of features in slack beyond the core chat stuff, like: 1. being connected to multiple communities and switching between them instantly this can be of course simply replaced by connecting to different servers in a tabbed terminal and use the terminal's built-in cmd-1/2/... shortcut, which happens to be the same as in slack. 2. meta data about others, like their timezone or how to pronounce their name…

Points 3 & 4 could be combined: like .plan, each user has an o+r .status file. Its contents are a user's status message, but its modified time is used specially to indicate when that user was last active. Anytime the usuc client writes a message to a channel, it would simply touch the .status file. And whenever an expanded usuc or some other tool lists the users in a channel (that is, all users in the group that owns the channel file), it would mark as idle any who had a .status mtime older than 30 minutes, say.
Post reply on HN