Niltalk - instant, private, disposable, ephemeral chat rooms [Go]

xuanbao · · 1429 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>Niltalk is an offshoot of some fun experimentation with Go. The hosted service is at <a href="https://niltalk.com">niltalk.com</a> and the source is available on <a href="https://github.com/goniltalk/niltalk">Github</a>. It could be used, for instance, quick and anonymous conversations that need to be taken out of sub reddits.</p> <p>The application uses Websockets (Gorilla) for communication and Redis (Redigo) for holding a few anonymous pieces of information temporarily. Channels have been use extensively to group Websocket connections into &#34;rooms&#34;.</p> <p>Feedback is appreciated!</p> <p>Edit: A word on the &#34;dispose room&#34; functionality. Any peer connected to a room is able to instantly dispose of the room, logging out all other connected peers. This is essential for the ephemeral nature of the project. If only the host is able to dispose, then it poses security and privacy risks as until the host explicitly disposes, the room is alive and a compromised peer would be prone to opening up access.</p> <hr/>**评论:**<br/><br/>Bromlife: <pre><p>This is <em>very</em> cool!</p></pre>importthis: <pre><p>Let&#39;s try it out <a href="https://niltalk.com/r/RqklS">here</a>. Password: the site you&#39;re on, without the domain ending, all lower case.</p> <p>Edit: room is down. Thanks to the guy who joined, typed &#34;neat&#34; and then tried the &#34;dispose room&#34; functionality.</p></pre>tashbarg: <pre><p>Which brings up the question if the &#34;dispose&#34; function shouldn&#39;t be restricted to the &#34;owner&#34; or at least provide some feedback to the owner about who closed the room.</p></pre>ecko3000: <pre><p>I like the feedback idea, perhaps all remaining participants in the room should be notified about who it was that disposed the room.</p> <p>Maybe the creator of the room could choose upon creation whether or not anyone besides them is allowed to dispose it.</p></pre>kailashnadh: <pre><p>There is no concept of ownership at all. When a room is created, it exists as a random piece of string with an encrypted password. Peers connect and disconnect. For an owner to be attached, there will have to be some form of registered users, which is goes against the idea of simple, ephemeral chats.</p> <p>A notification of who disposed of the room to all the connected users is a good idea.</p></pre>Kabukks: <pre><blockquote> <p>For an owner to be attached, there will have to be some form of registered users</p> </blockquote> <p>You could set a session cookie to identify the owner of the channel: <a href="http://www.gorillatoolkit.org/pkg/securecookie" rel="nofollow">http://www.gorillatoolkit.org/pkg/securecookie</a></p></pre>kailashnadh: <pre><p>Using a cookie to track ownership can be problematic. Browser could lose a cookie. User may need to access the room from a different browser or device altogether. Providing an expectation of ownership controls that only works under certain conditions can be confusing to the UX.</p></pre>jayrox: <pre><p>what about a majority vote on room disposal? hitting the dispose button auto counts as a [yes] vote.</p> <p>everyone else sees: guest a has requested disposal: [yes] [no]</p> <p>or if only one person is in the room, and they hit dispose, no vote.</p></pre>kailashnadh: <pre><p>I don&#39;t know if that works with the exact goals of Niltalk. A vote system, or any such dependency could be a problem in case of emergencies where one needs to quickly dispose of for privacy reasons.</p> <p>Then again, the service is intended to be used by small private groups of people who&#39;re explicitly invited to have a short conversation, unlike in a public context where someone could randomly hit dispose to annoy participants.</p></pre>jayrox: <pre><p>good point, i would expect people in the chat to be invited which would/will reduce trolling.</p></pre>jayrox: <pre><p>good point, i would expect people in the chat to be invited which would/will reduce trolling.</p></pre>fr4nk3n: <pre><p>Very nice! Small request, could you change the websocket connection to use a tls connection?</p></pre>kailashnadh: <pre><p>Thanks! Websocket already connects over &#39;wss&#39;.</p></pre>tashbarg: <pre><p>Username entry field seems to have some requirements (at least longer than three, not sure if more) but fails to tell them to the user.</p> <p>It even complains &#34;Please match the requested format&#34; but, alas, no format is ever requested.</p></pre>kailashnadh: <pre><p>Fixed.</p></pre>tashbarg: <pre><p>I just saw it and thought I&#39;ve overseen it earlier. I already started to get embarassed ... impressive reaction time.</p></pre>ecko3000: <pre><p>The room and username textboxes would look better if they were aligned: <a href="http://i.imgur.com/pYsuKYF.png" rel="nofollow">http://i.imgur.com/pYsuKYF.png</a></p> <p>Also on the join room page, if you give a password that&#39;s too short it gives the same message, &#34;Please match the requested format&#34; but no format is specified.</p> <p>Those very small nitpicks aside, this is a really nice project. Simple, functional and useful -- great work! Also I like the fact that no logs are kept. This is one of the best things I&#39;ve seen in this subreddit.</p></pre>kailashnadh: <pre><p>Cheers! Will add the text messages.</p> <p>The text box misalignment is not normal. Can you refresh and try? <a href="http://imgur.com/n3tMPgr">This is how</a> it&#39;s supposed to look (tested on Chrome and Firefox on Ubuntu).</p></pre>ecko3000: <pre><p>Yep looks fine after a no-cache refresh.</p></pre>ecko3000: <pre><p>One more tiny nitpick on grammar: on the homepage (and in your OP edit) it should read &#34;dispose <strong>of</strong> the room&#34;, not &#34;dispose <strong>off</strong> the room&#34;.</p></pre>kailashnadh: <pre><p>Eek, fixed.</p></pre>SuperGabe: <pre><p>Out of curiosity, where are you running the service? On Amazon?</p></pre>kailashnadh: <pre><p>Togglebox.</p></pre>raluralu: <pre><p>This is awesome! I have additional feature request: Instead of having password protected room you could implement SRP to protect conversation and only clients would know plain text. This is additional security since no plain text information is available on server.</p></pre>DangerousLiberal: <pre><p>Have you seen talk.gg?</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1429 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传