@seancorfield: I know @denik - should I relay something to him? (He seems to be online right now as well)

@martinklepsch that would be great! I get the impression he set them up early on and then didn't use Slack much after that...?

he's been active recently

I made a bunch of changes to the wiki. Moved the chat app page contents to the home page and deleted that page. Added some content to all the other pages. Please check it out and add moar. Thanks. https://github.com/clojurians/clojurians-chat/wiki

@seancorfield: I’m quoting you extensively w/r/t IRC (things you’ve said in this channel) on the IRC wiki page. lmk if that’s not something you want (or edit it yourself https://github.com/clojurians/clojurians-chat/wiki/IRC

Just remember it's all "IMO" 😸

The bike-shed needs painting again. What color? https://github.com/clojurians/clojurians-chat/wiki/Bikeshed

wiki love fest: https://github.com/pkobrien?tab=activity

@jaredly @seancorfield just because one implementation of a bridge does not handle multimedia integration very well does not mean that all possible bridge implementations would suffer the same

Also, not sure why you'd think that "fake handles" would be an issue: why not just clone whichever handle the person is using on whichever side to the other side (unless there is a collision and then just append _N).

It sounds like the bridge you've seen just was poorly implemented to me.

@mfikes: I too have seen the Slack lockup when switching back to it (but it didn't feel like it was quite 10 seconds).

@rafd: Can I ask you to sort of take ownership of this page so that it accurately reflects whatever you want it to say about Braid? https://github.com/clojurians/clojurians-chat/wiki/Braid

@johanatan: https://github.com/clojurians/clojurians-chat/wiki/IRC#irc-bridge

@johanatan: position appreciated (and added to the IRC wiki page, looks like)

@jaredly and @johanatan Thank you for capturing all of this IRC stuff on the wiki.

@johanatan: your contributions are valuable and much appreciated. please add yourself to the list so we keep you in the loop https://github.com/clojurians/clojurians-chat/wiki#who

Was there discussion of Vector/Matrix as options beyond noting that their web client isn't quite there yet?

@arrdem: welcome

@meow: thanks! been following this from the sidelines for a while, thought I'd chime in at least.

awesome

we just started capturing content on the wiki so take a look and pitch in if you want https://github.com/clojurians/clojurians-chat/wiki

I know vector/matrix is mentioned in there somewhere

I just added a blank page since there wasn't one 😐

Just a note on hosting... at present I'm funded to the tune of $65/mo to run http://conj.io, operating costs are nearer $25/mo, could be persuaded to offer hosting to something like this using money already coming from the Clojure community for other projects.

Since amalloy and raynes have pretty much abandoned lazybot on Freenode's #C03S1KBA2 I've offered to take over running the bot as such for these reasons although it's not clear if that's gonna happen or not.

@arrdem: tyvm

@tcrawley: can you work with @arrdem on his funding questions?

new page: https://github.com/clojurians/clojurians-chat/wiki/Administration

@arrdem: Toby is leading the effort to hook up with an OSS group to handle funds

for clojars and this app

@meow: gotcha. @danielcompton does this tie together at all with clojure/org?

Just a note for discussion, I don't know how many of you use http://lobste.rs, but I'm highly opposed to having whatever it is we switch to be truly open access.

and @gjnoonan is doing the hosting and admin now

for the slack invites and a test mattermost setup

we have no more integrations available in our slack team

not sure if you need that for your bot stuff or not

@seancorfield would be the one to ask about that

I think that the history of IRC servers and IRC drama is evidence enough that if we offer a properly open chat platform, it will eventually be abused and used to harass people in manners which the unfortunate administrators will have great difficulty responding to. I think that the Lobsters approach of making you get an invite from an existing user is interesting in that it means you can't just spam smurf accounts and there is a chain of accountability in the case of a user who invites multiple abusive accounts to prevent such abuse.

I understand that we want a low friction "newcommer first join" UX, but I think this does also need to be weighed with the potential for abuse.

@arrdem: I agree. It wasn't burdensome at all to get an invite to join Slack (since there were many offers of such on my Twitter stream already).

I added your concern to the wiki - feel free to discuss here and then update the wiki, please and thank you https://github.com/clojurians/clojurians-chat/wiki/Concerns

we also have an IRC page for stuff that pertains to that

@arrdem: I think you've raised a really good point. I agree.

slack is a breath of fresh air compared to open / spammed /trolled environments

I also note, and admit that I have a lot of personal bias here, that whatever platform we jump to / create should be able to put a tight leash on bots. See https://github.com/hiredman/clojurebot/issues/5

we probably should flesh out the concern on the concerns page and then throw some features into the main page and wherever else they make sense

just read that issue and all I can think is WTF?!?!?!?!?

and it still hasn't been resolved?

Yep.

WTF!!!!

I agree. But both lazybot and clojurebot are entirely unofficial and report to nobody so there it sits.

Well, I can't see that fitting into our vision for this new chat system

Part of why I want only official bots 😛

yeah

This isn't going to be the wild west

https://github.com/clojurians/clojurians-chat/wiki/Code-Of-Conduct

feel free to make suggested changes to that

It's pretty much just the existing CoC copy/pasted into the wiki

@arrdem: You should just clone clojurebot, remove your name from the list and release it as some endearingly-named bot.

[release it into the IRC channel that is]

@johanatan: if I were more mean-spirited or actually cared an effort to ddos clojurebot and force progress on this issue could have been made long ago. I think that adding more bots is rude and misses the point and so have refrained.

So that issue is pretty much WTF, but have there been instances of abuse in #C03S1KBA2 or #C03S1L9DN on FreeNode?

@arrdem: and you're the bigger man for that

We've had a few instances of trolling, a user chare a while back was help vampiring for a few days. bitemyapp and I had a good time baiting it and everyone else pretty much left it alone.

I don't see adding more bots in the same way apparently although admittedly I lack context/history. Bots are intelligent agents too.

Also, how do you ever know if those other handles on the internet are bots or not anyway?

That incident aside I'm not aware of any real issues in either irc channel although my history is short.

Clojure benefits greatly from being pretty niche in that regard unlike #python and #haskell which have to work pretty hard to control channel volume and content.

I think a gated community with easy access and easy exit is the way to go - meaning make it easy to join but also easy to remove trouble

#clojure is less niche than #haskell? You wouldn't know it by the number of open positions in the job market for each

I'm purely going by number of active IRC users here. #clojure is no more than half the size of #haskell and related channels.

Oh, interesting

I can get a real count one sec

haskell has been around longer and might have more irc users completely independent of market demand for job positions

Perhaps all the Clojurists haven't given up on CommonLisp or Racket and thus their time is divided?

694 users logged into #clojure

1464 users logged into #haskell

I was almost on the money

Also, perhaps Clojure is a more naturally grok'd language so you don't get as many newbs asking as many "how do i..." questions.

didn't clojure irc drop a lot when the slack team got created?

I'm not gonna argue that one either way. I think it's more a question of demographics and associated user cultures.

I barely used it

pkobrien: activity dropped, user count didn't.

AFAIK.

the rate of newbies went to ~0

all the old hands are still around

I think someone said that most irc accounts also have slack accounts

Yeah.

Yes, demographics and associated cultures is what I was getting at with alluding to the CL and Racket grey beards who don't need help from IRC to use Clojure

That's definitely true.

some of us grey beards enjoy providing help

@johanatan: not that I think it matters, but I'd argue it the other way. I think that the kinds of people who use Clojure have real jobs and aren't able to / don't choose to sit on IRC during the day answering questions and talking shop whereas the Haskell folk love the baby and expend far more energy talking about it and helping out.

Case in point, at Factual amalloy was the only one who really used IRC during the day although dbash and I were both logged in and we were in an org with ~30 clojure programmers.

@meow: haha, true. but some are grumpy. Lispers in particular have not historically been known as the most congenial (rightly or not).

@johanatan: need to work on that enter key control mate 😛

@arrdem: isn't that another way of saying what I said re: grey beards?

@johanatan: maybe

i.e., they have lives outside of the language they program in

@arrdem: it's not lack of enter key control. actually it is one of the few poorly designed aspects of Slack's UX.

Oh right shift-enter it's something I've gotten used to by dint of participating in several other very very active slacks.

For me, it's that auto-complete stops doing its thing one character too soon

[sometimes my hands type the entire token I'm searching for before enter]

and that results in a message going to the channel of nothing but the handle being sought. arg!

[like anyone would ever want to send that message]

i.e., the "people matching @xxz" list should still contain one item when it is a full match

but it doesn't. it contains zero items. and an enter at that point of course doesn't select the non-existent item but rather sends an essentially empty message to the channel

So if we end up going the route of writing our own code for this, would be really cool to see this annoying aspect of Slack fixed.

@johanatan: you know where to post feature requests

@arrdem: can I ask you to make sure the wiki reflects your concerns about bots and any suggested ways of handling them in our chat app, as well as anything else important to you?

@meow: yep working on it

sweet, thanks

this place is great

@meow: actually I don't unless you're referring to braid (and I didn't think we'd made any decision regarding it yet).

pkobrien: Just a note for next time since we're committed to GH wiki, http://hackpad.com is amazing because it's real time, edits are tagged by who made them, makes using inline comments for discussion easy.

@arrdem: It’s not too late - not having attribution on changes in GH wiki is annoying

(IMO)

@johanatan: you lost me

what does braid have to do with what I suggested

@cfleming: shout out to the #luther days

yeah, who said we were committed to GH wiki

I assumed by dint of having been repeatedly pointed there 😛

cuz datz whats we gots rights now

I know @meow likes a simple free-love wiki with none of that new-fangled stuff the kidz like

got the ball rolling, didn't it

No complaints here

free love

hah

set something up that's better and I'll play my game over there

does not matter to me at all

sgtm give me a minute to finish reviewing an old and memory-filled hackpad, grab another 🍺

@meow: you suggested that I knew where to submit the "feature request" (which is really not a feature request but rather a "heads-up bug to avoid")

And there was no other interpretation of your suggestion that made sense to me

In my opinion it would be out of place and premature for such an idiosyncratic glitch to be singled out on the wiki as something for our rewrite to avoid

At the point where there is an actual GitHub setup with code in it, sure, I would submit an issue

Hence my conclusion that you must be talking about braid

https://hackpad.com/ep/group/wnikaeBENEE

I'm slowly moving pages over

no, just that if you phrase what you wrote in a positive fashion - describing how you want it to work when there is a full match - you could just add that to the list of nice-to-haves on the home page

Umm ok but it seems like such a minor thing. I'd rather wait and see it start to get baked and then if I see the issue or room for improvement file an issue

why

Ok fair enough. I'll add it tomorrow

when the user types an autocomplete value that is a complete match it should not mess up the Enter key the way it does on slack

Ahh okay. I didn't realize others were in agreement with me on it

doesnt matter

we're just capturing as much input as possible for review /filtering/prioritizing later

kind of like brainstorming

Ok

Is there a "things that suck about Slack" section?

Seems like most appropriate for there if so

so don't feel the need to self-filter - if there are glitches that annoy you then describe how you want it to behave and add it to the list so we know what needs to be coded from the get go

Ok I'll create things that suck about Slack if it doesn't exist already

there are whatever sections I've come up with so far and some that others have contributed and I want to keep things loose and flexible and get more contributions and we'll just keeping shaping this thing as we go

this is the messy, artistic, brainstorming, griping, bikeshedding, concerning part of the process

the engineering will come later

Home, CoC and concerns all on hackpad. Still moving things. You should be able to just click the link and start adding documents.

click what link

https://hackpad.com/collection/wnikaeBENEE

This collection is empty.

now you get to hold my hand @arrdem

what do I do

Sure since this is my fault anyway.

As I have the auth settings right now, clicking the link should show you a list of documents. Lemme log out and check this claim.

Got it I had permissions wrong.

@meow: refreshing should show you a list of four documents you can look at.

@meow: if you log in / create an account you should be able to edit any/all of them.

can't I auth with my github acct

nvrmnd

can use my google acct

it wants my google contacts and I don't want it to have them and there is no way to remove that request for perm WTF

It doesn't spam anyone, it just indexes them by name so that it can give you lower friction "add user to document" behavior.

so I hit deny to the whole thing and now I'm at their home page with no idea what that means

I want it to have my email and profile but not my contacts

They will let you create an account with just an email not an oauth id

I don't want to do that

all the other apps let me take away perm to my google contacts

not happy

so basically by choosing deny I do not have an account

signing in with my FB it appears to not try to get my friends - we'll see

omg, overwhelming intro page

I don't like that slack makes me go all the way to the right and click twice to edit prev post

I'm always correcting my typos and its way too much work

see - there's another one - screw it

uparrow will let you edit the last one, but up twice won't let you edit the one before that etc. Slack actually has some really interesting permissioning problems around who can edit messages and when.

do I have to actually read this intro info?

IMO no.

I didn't at least.

good

If you type markdown in, the editor will autoformat, but if you copy/paste markdown in it won't figure it out.

I read it anyway - probably just made things worse - how do I get rid of it or what do I do from here

You can click on a file in that collection list to edit it, or you can create a new file by clicking the file+ button top left, edit it, click the green link next to the title, set permissions to public and then add it to the clojure-community-development collection

its slow as molasses in january

I'm not seeing a collection list - do I need to click your link up there again

probably.

okay, I'm following it

@meow: https://clojure-community.hackpad.com/ you should be able to click the link and just create hackpads here.

all the internal links need fixing

Yeah I can work on that.

I'll also move all those hackpads over to the hackpad space where anyone can edit. Looks like the list I shared with you is tied to my account.

I pinned the home page and I'd like it to stay there as it is meant to be an introduction and overview - I'm flexible on all the rest

If you can create a new document and add it to that collection we're all good to go and can ignore the new link I just posted.

Otherwise we have a problem and need to make the transition to using their real workspace tool

how do I get a permalink for say, the Slackpocalypse page so I can paste it here and there to get people interested in what we are doing

the file links are permalinks

Eg https://hackpad.com/Slackpocalypse-GRIaf1RgP5D

gotcha - didn't see the url change the first time I did it

created a new pad and it opened it in a new tab

not sure I like that, but whatevs

new pad is above the home page now

why

just my temp view of the world

Ok yeah you didn't make your new pad public so I can't see it.

😐

the workspace may be in order.

I see no way to make it public

add to collection?

it doesn't show me any collections - how am I supposed to know what to do there

There's a green link icon to the left of the title. Clicking on that will let you make it public.

Type c into the collections search and it'll show up

Agree it's shitty, maybe enough onboarding friction to not be worth while.

ok, made it public

Worked great for a single huge document with several editors ~6mo ago, hence my suggestion.

no, if we get through this then I'll know how to help everyone else

if you just click the "add to collection" button you should (I hope) be able to type some prefix string of "clojure-community..." and see my collection as an option.

there it is

do you see it

Yep!

awesome.

I survived

Heh

good enough - lets make it work

better than the gh wiki

The really compelling feature is comments. Just add a new line, type // c/c++ style and away you go.

Comments are tagged with your name and can contain arbitrary text/markup.

So if you don't like something you can just start discussing it inline

nice

very nice

good call - this will be very good

@meow: made changes to the wiki re: Braid: https://github.com/clojurians/clojurians-chat/wiki/Braid

Yeah that was the killer feature in the previous use. The document was quite the loaded rant by yours truly discussed and edited by a bunch of people mainly using the inline comments to provide long form discussion

@rafd: awesome - just in time for us to move it to this new place

excellent

btw: https://clojurians.slack.com/archives/clj-chat-project/p1452416603000133 (posting there so as not to derail this discussion, can discuss in that room instead)

Hmm, this was probably already beaten to death - why not a layer over IRC? I've scrolled above and seen something about this having been discussed elsewhere, but is there any link to that?

cool, I'll be over there in a minute - need to take a break - be back in a few

@arrdem: will show you the irc page on this docpad thing we have

@jaen: @meow https://hackpad.com/IRC-3Mg57eCXdkB

Thanks!

bbiab

@jaen: sure!

@rafd: can I walk you through moving the Braid page over?

So you get to see how this thing works, not 'cause I can't do it in seconds.

@arrdem: sure

Morning

hey @gjnoonan

i can't see multiple pages, do i need to sign in?

Eek 290 unread messages in this channel alone to read

The TLDR is that I'm pushing a move to hackpad from the wiki

Also some cautionary questions about the organization and administration of whatever the new chat platform is wrt signups, potential for harassment and administrative oversight of bots.

Because?

Mainly because I think that the GH wiki format is poorly structured for recording discussion of open questions and I've previously had very very good success using hackpad's inline comment features for this.

A lot of this channel has been "go write it on the wiki" so I thought that a tool with better support for comments and discussion would be welcomed.

I was going to create us a jira and confluence set-up :-) but cool I will look into this hackpad, heard of it but never used it

Not the JIRA D :

Just so you have an example of a really really actively commented on hackpad doc, check this one out. I'd appreciate it if you wouldn't edit it for historical interest. Warning: may be inflamatory re clojure gov't in this crowd. https://hackpad.com/95-Clojure-Theses-lHCAQmymizf

@rafd: all you should have to do is create a new document, set it's access permissions to public and add it to the clojure-community-... collection.

Ho-hum. What's there on IRC in the hackpad doesn't convince me so far it's a bad choice to be honest - things like rich messages, account management, troll prevention feel like something that can be appropriately solved on top of IRC. And this Matrix thing seems like it solves some of the problems plain IRC has for us already.

@rafd: the tricky bits are that the UI around changing permissions is kinda odd, you click on the link to the left of the title, and adding to a collection requires that you disable the editing overlay by clicking on the pencil near the top right.

For one - I can't see what's so unworkable about having IRC server that only lets voiced people chat and voicing being based on registration in the platform. For rich messages - platforms like Slack already have to do some inference on how to display content, why couldn't some proxy over IRC decide on that as well. To me all those issues are solvable and would neatly bridge both sides of the wall.

jaen: Personally, my introduction to the Clojure community was the IRC channel. I'd love whatever we build to "just work" and fit in atop the existing IRC channels rather than killing them.

But maybe I'm not seeing something?

Yeah, I've been hanging around in #haskell, #rust or #C03S1KBA2 for quite a bit before I've even known Slack existed.

Slack is slick, that's for sure, and I do quite like that, but sometimes you just want the simplicity of IRC.

jaen: As to the actual infrastructure problems, I'd tend to agree. The simplest thing that could possibly work would it seems to me be to write (or wrap) a Clojure IRC server with a database persistence layer and throw a React/Om webapp atop it.

Yeah, a smart proxy over or an IRC server written in Clojure that also exposes a web client and management seems like the obvious solution to me TBH.

Right. How about we take this to #C0J20813K since that's where @rafd is seriously threatening to build something.

Or Matrix, this also seems like an interesting choice of transport. Because whether it be IRC, Matrix or custom websocket thing the most things we would want to solve are orthogonal to the transport.

Right, sure.

I'm not sure if I'll be having any time to help out but lurking/offering incidental comments is something I can do for sure ; d

@rafd: Where's the most useful for us to have this conversation. Is this a direction question for here or for there?

i think there's 3 conversations currently to be had: 1) ideal clojure chat client, 2) plan for clojurians re: slack, 3) braid stuff

Don't want to :shit: up your channel if you're dedicated to Braid or something else 😛

i can just make a new channel

or,... perhaps we should make a new channel

and i'll rename mine to braid

By all means rename to Braid.. I'd keep the 1,2 questions here rather than forking.

In which case jaen pray continue

Well that's about it for my input re: that to be honest, at least initially. I'll be interested to hear what people that are not partial to building it on top of IRC/Matrix have as counterpoints as I may be missing some obvious holes building the platform that way would have. And then maybe that can be expanded upon if we know what are the problems.

I think.

But I do have another question - someone mentioned considering datomic as the data store. And apart from the license IMO another glaring weakness of datomic is the inability to limit or sort results (at least easily), which seems something that's very important for a chat client.

@jaen: matrix is being taken into consideration as I am a fan of it myself, as well as a few others

Just a data point on the "just use IRC" front, it looks like there isn't an existing Clojure IRC server worth speaking of, nor a client which is actively maintained. There are a few also older Java IRC servers and clients which could probably be built atop.

Also IRC isn't an overtly complex protocol IIRC (I remember bashing together an IRC bot long ago with HTTP kit and it didn't seem too hard) and with a language of high power density like Clojure is it wouldn't probably be to hard to build it on top of aleph or somesuch. And as you mention, there's certainly Java to reused.

Yeah. It'd be an interesting project to just take something like aleph and crank out an IRC implementation. Shouldn't be too hard.

But as with all things time is the limiting factor.

That's true. Slack isn't breathing on our necks... yet, though. So there's certainly some time to be had.

I'm good with assuming that the implementation of an IRC server is trivial as a starting point.

It'd be an interesting project to try and figure out what existing objections to IRC as a protocol are.

Exactly. I sort-of got an impression it's being assumed not propped up by concrete arguments (though I haven't been following the channel since beginning), so it would be good to collate any objections and see how solvable they are.

http://blog.cognitect.com/blog/2014/7/22/transit

Transit and Datomic are both in the "won't touch" bucket for me.

Hmm, I can get datomic, but why transit?

The big win of Transit as I understand it is for sending structures which either use complex encodings which you want to recover, or have either recursive or repeated structures which can be optimized relative to JSON or EDN. I don't see that this project (or anything else I've worked on) requires either of these features when JSON "just works" and everyone's familiar with it.

good insight

Well, with JSON you have to write some boilerplate to recover the types, which Transit has built-in, and funnily enough JSON objects are slower than Transit encoding.

Also I'm generally bearish on Cognitect product until proven otherwise. Call it bias.

But I can understand wanting to align more with standards that the general populace uses even if transit is more convenient.

Well, I do agree about being leery of datomic (I, for one, don't exactly trust a database that can't limit/sort reliably) but I'm pretty neutral-to-positive on transit.

It nicely solves problems you would otherwise have to.

to me all this low level stuff is just trivial crap that one has to sort out with little value add - by that I mean there is a server that contains data, and there are wires that transport data, and there are clients that send/receive data - the mechanisms of moving the data are just technical and performance details - the value is in the shape of that data and what it allows you to do with the UX, and how well you execute the UX

these protocols have been around for ages

To be completely blunt, I trust Cognitect to develop elegant solutions to the problems they have chuck them over the wall to the rest of us, and then to utterly fail to manage them as open source projects in any way not directly aligned with their interests. This is also my assessment of the state of Clojure/Core in case you didn't read that original hackpad I linked earlier. JSON is easy in the Hickey sense of the word. One less thing to learn in approaching a project which is going to be 90% UX, not performance.

that's okay, Cognitect still gives us a good platform to build on

If JSON message encoding proves a problem, and I will be awestruck if it is, we can provide alternate encodings/decodings easily.

Yeah, I can see how you can view Cognitect and Clojure/Core. I also usually end up being pretty annoyed at Clojurescript maintainership, but maybe that's just me : V

That is probably a sensible argument against using transit.

But if you needed to retain typing in the messages (not saying it would be necessary) what would your proposal be?

Building schema+coercion boilerplate, using JSON schema, something yet else?

just some context - in the python world there is twisted and has been for many years - event-driven multi-protocol networking engine

using twisted you can create a server app that supports a wide variety of protocols in a single server and mix and match them all you want

this stuff has been done to death

there is no magic in these protocols any more

return -E_NO_MAGIC

you could envision this new chat app as having a custom protocol tailored to clojure as long as it also supported IRC for integration with tools that expect to talk irc

That makes sense, I suppose.

its all just data sharing

we aren't trying to invent a new protocol, and there is no reason to not support multiple protocols

Also, if you consider it what is wrong with providing multiple serialisations - if you need rich typing you get transit, if you don't want to use it - you get JSON (with or without type hints).

so don't think it has to be an either/or decision

> we aren't trying to invent a new protocol Yeah, exactly my intention behind asking about ruling out IRC.

at some point you have to manage your options to limit the amount of work, but a server can handle whatever you are willing to write the code to do

I mean... just have /api/sockets/:channel/:format/ be websocket results

or something

It'd be interesting to offer websocket streaming connections to any channel w/o login, require login to post.

maybe implications for stalking/management.

I think offering unauthenticated sockets as long as the channel is open doesn't lower any privacy guarantees not already had.

I think the interesting challenges will be things like "can the braid view of how to manage messages work for a large community of devs"

Unless the client somehow logged who had seen each message, then yeah, maybe.

someone else might want to go with a "slack is the bomb it's just missing a couple of things and then it would be perfect" approach

https://clojurians.slack.com/archives/community-development/p1452421123001225 that's going to be the real kicker

I don't know and don't care. I'm offering to work with and advocate on behalf of any and all teams that want to work towards a solution. In the end the community will have to decide what to go with and I will abstain from that decision/vote/whatever

Well, I for one don't mind the room abstraction and Slack is pretty close to perfect IMO (when I first came across it was like OMG, Hipchat and whatever have never done it for me)

But the tagged conversation things idea of Braid

Also seems really interesting, if different.

Google Wave also seemed pretty interesting, though.

I think both room and tagging idea can be combined to be fair, to offer greater flexibility

we might start with multiple teams taking different approaches and evolve towards some ultimate hybrid

who knows?

doesn't that sound funner than f*ck?

heh

@gjnoonan: I suppose. You get default channel-per-tag setup for example and then you can tailor it to your liking.

/usr/share/badwords

Braid is a really cool idea... maybe it needs a root tag to bind everything else together at least for newcommers.

Though it might result in conversation become somewhat confusing when someone refers something in a different tag you don't subscribe to.

as long as I can do reactji performance art I will be happy

ahaha

@meow: no promises 😛

ha!

my thinking re: https://clojurians.slack.com/archives/community-development/p1452421123001225 is that forums are very similar to concept to Braid and handle large communities decently (but traditionally have not been real time) and still have threading issues

@rafd: be interesting to know your thoughts on something like discourse

was just about to 😛

Discourse has taken it's own approach to threading... but it feels very heavy

I have some sketches of extending what I have in Braid to allow for lightweight branching, b/c tangents still happen, but I do want to avoid full threading (like on reddit for example)

I think forum-like functionality, with a chat-like feel is a nice middle

@arrdem @jaen & others, I’ve been wondering whether an IRC server with a set of blessed plugins to try to emulate slack and a CLJS front end might work too.

Someone on HN said that the IRC protocol is incapable of supporting multi-line messages - no idea if that’s true.

Yeah, that's basically my idea, though I must admit I thought as it of monolithic not pluggable.

But I guess pluggable is better

I don’t think such a server would have to be written in Clojure

@jaen: No, I mean just take the most sane IRC server out there and use that. There are standard extensions IIRC to provide much of this stuff.

I definitely don’t think we should write an IRC server - that would just be bloody minded yak shaving.

Oh, I see.

irccloud is probably good inspiration for that approach.

I guess I just have NIH and overengineering in the back of my head P ;

I don’t know to what extent you can hide the horribleness of IRC if you really try.

Well, at least, I’d want to see a really compelling reason to do so. There may be such a reason - perhaps not supporting all of IRC if dropping some functionality makes the implementation more sane, for e.g.

I'm a big fan of "minimal working concept" approach to getting things started

XMPP would be the other candidate, but my impression from looking at HN threads for things that try to do something like this on top of it is that it gets super complex very quickly.

> that would be bloody minded yak shaving SIR HAVE YOU IGNORED THE LAST TWO YEARS OF MY WRITINGS

IRC may be similar.

@arrdem: You’ve written things in the last two years?

Re: multiline messaging - that seems to be true according to the RFC: > IRC messages are always lines of characters terminated with a CR-LF > (Carriage Return - Line Feed) pair, and these messages SHALL NOT > exceed 512 characters in length, counting all characters including > the trailing CR-LF. Thus, there are 510 characters maximum allowed > for the command and its parameters. There is no provision for > continuation of message lines.

@jaen: Right, that’s basically shit in this day and age, right there

True, but the server/proxy could just collapse messages according to some criteria for non-IRC users.

jabberd

lots of this stuff got tossed around on the HN announcement of mattermost

And Matrix quite possibly solves those problems as well.

often by people with only a superficial understanding of what they were tossing around

I need to read the fine manual again, but I think that Matrix deals nicely with most of this.

@meow: Right. Pretty much whenever I see someone saying “why don’t you just….” someone who’s actually done it comes along and makes a custom protocol sound pretty good.

I recommend taking the entire content of the HN thread and just sort it by word to find all the options tossed around and then evaluate them intelligently in the super cool hackpad that got set up recently

Anyway, I’m off to bed

Night all

gnight

> 4:40am

I'm out

have fun with hackpad!

tyvm

I don't really do HN, is there any useful stuff in that thread and if so - any link?

two relevant threads as I'm closing out: https://news.ycombinator.com/item?id=9770322 https://news.ycombinator.com/item?id=10386847

Thanks

https://hackpad.com/Chat-Protocol-Criticisms-tQan7YQyGRt

https://news.ycombinator.com/item?id=9770322

d'oh

as for usefulness, who knows - like needles in haystacks - might be some value in there but trying to sift it out...

I read/skimmed most of it

lots of folks say "just use IRC as the foundation" and yet nobody does it - that kind of says something right there

wanna know how to win the lottery? just buy the winning ticket. simple

its all simple until you try to do it

I'd rather come at this as "what do we want this app to do?" rather than "how can we fool ourselves into believing there is an easy solution already out there that everyone else is too stupid to see"

I mean, we're talking about some really old protocols

jabber got hyped to death and was supposed to solve all these problems already

does anyone even use jabber any more or ever?

https://en.wikipedia.org/wiki/XMPP

based on xml - bam!

what does that say to you?

bloat?

In February 2010, the social-networking site Facebook opened up its chat feature to third-party applications via XMPP.[14] Some functionality was unavailable through XMPP, and support was dropped in April 2014.[15]

Similarly, in December 2011, Microsoft released an XMPP interface to its Microsoft Messenger service.[16] Skype, its de facto successor, also provides limited XMPP support.[17] However, these are not native XMPP implementations.

so, yeah, just use xmpp

easy

I don't think there is any protocol that makes this problem easy.

so why focus on the protocol

focus on what you want the app to be capable of letting the user do and then do whatever you have to to make that work - bastardize the daylights out of some existing protocol or invent a custom one that gets the job done

by the way, since I mentioned python twisted earlier and how it was easy to create event-driven multi-protocol network apps, right?

all true

no killer apps were ever created using it that I'm aware of

there is no significant value in protocols

imo

the extension cord that you use to plug your lamp into the wall outlet is just a necessary evil

gotta have it - but all you really care about is the light from the lamp

create an led light while everyone else is using florescent - don't focus on the extension cord

From my point of view it depends on what you want to create. Do you want a product you can monetize? Create slack. Do you want a thing there ppl can build upon and create infrastructure for it? Create a protocol.

These are just two different goals

@sveri: my take is that we want to focus and support the community in building a chat application for its own use to replace slack

based on that how do you see going about that? we don't want to monetize it. And we don't necessarily want people other than some team of volunteers from the clojure community to be able to build upon it.

It is a custom chat app, by us, for us.

I followed the discussion closely, so yes. I understand that.

cool

I want to make sure I understand your point of view.

Everything has it's advantages. building a protocol, you will get a lot of stuff for free, if it succeeds. If it doesnt, well, a lot of time has been wasted with not much outcome

I am fine with building another slack

but then, it's just another slack

what do you mean by "building a protocol" and can you give some examples of what you get for free when you do so?

Well ideally even if you build another Slack, you in effect will be designing a protocol

And the Om way will probably suggest very strongly what that will look like

EDN maybe? Datomic?

So if it is good (and it should be), then release the protocol later

If you use an existing protocol, then you presumably get some sort of engine for free (like IRC for example).

I still want to hear @sveri answer

I'm sure there are Java and JavaScript engines for IRC

@meow: XMPP for instance. People have build clients for it, servers, mobile applications and whatever I cannot think of. This is what you get for free.

That's not building a protocol-- that's using an existing one

But on the other hand it is a totally different beast to develop a protocol

those two replies are the crux of my confusion

I mean creating a new protocol and writing another slack are two totally different things

yes

My family just came back for lunch. I will respond later, have to leave for now, sorry

He meant "build on a protocol" in place of "build protocol"

and the freebies come from adopting an existing protocol, not designing a new one, right?

Correct

ah, gotcha

@johanatan: Nope, I meant building a new protocol and the freebies come frome ppl building onto that protocol, but only if it succeeds...off for now

ok, sure

So I'm not convinced that because no one else seems to be seeing the easy way to combine existing techs, we can't. But also I think there's little value in that

that also makes sense

I don't see that happening

not my goal to design/build/promote a new protocol for public use

@sveri: that may be what you meant one time but at least one other you meant something else

See: https://clojurians.slack.com/archives/community-development/p1452427411001348

he probably meant that's what you would get if you created a new protocol in the same vein as XMPP - one that is successful

anyhow, I think we are clear enough on this

Oh right gotcha

I think Om/Datomic would very strongly suggest a quite natural "protocol" so this is all kinda moot

And it could be released if there were some reason to

I am only interested in designing a single chat application (multiple clients, of course) for use by our community to potentially replace slack

the thing could be user customizable with plugins and whatever - that doesn't matter to me

it will be perceived as the chat app that we use, even if each user modded it to look different

or not

one app

I think the problem with adopting a protocol is that all those freebies come with strings attached - one easy example is that they bind you to the protocol so you can't easily morph it to solve the problem in your main app because that would break all the freebies

so, maybe not so free

designing a protocol for widespread use - I just don't even want to contemplate that - it is completely off the table as far as I am concerned

if it ever happened someone else could drive that effort - I don't even want to think or talk about it

for me this is all about eating our own dogfood, solving our own problem

I don't need a protocol. I need a chat app. And so do you.

as good as slack or better

and better might mean just more refined or it might mean radically different

midnite vultures by beck is good fun

Oh ya totally agree. Was just saying that there will be a "protocol" whether you design or release it. But ya it makes sense to keep it private/eligible for change

What happened to the Braid page on hackpad - I don't see it https://hackpad.com/collection/wnikaeBENEE

@johanatan i meant that all the time. The response you refer to was an example of a protocol that @meow was asking for.

@meow i am just talking about different options and approaches here. Not less not more. If i had the choice i would vote for a protocol. That said i agree most ppl just want to build a chat app, which i am fine with too.

wow, lots of activity. Can we get a daily summary wiki page? 😄

I agree with @meow that we need to design for our specific needs rather than some kind of standardized, public protocol. The promises that makes to the world at large (‘Hey, we’re an open-source Slack!’ or ‘Hey, we’re IRC for the 21st century!’) will require too much dedication and work to maintain.

I also agree that IRC is the wrong backend for this. It’s too limited, hackable, destructible, etc. In my mind, there must be a reason why everyone from Slack to gitter to AOL Instant Messenger to Jabber rolled their own from the dirt rather than relying on IRC.

designing a protocol would be several orders of magnitude more work than just building one system, with a huge risk of getting it wrong in ways which are then impossible to fix.

Plus, this hypothetical protocol will still need (preferably multiple) reference implementations.

Yep. Fully agreed. This needs to be ‘just another FOSS project’.

hey @meow: take a look at http://tonsky.me/blog/datascript-chat/, might be a really nice starting point.

Yeah, having a client side database is cool and powerful and all and I love me some datascript, but it all depends on how complex the client will be. I can see distinct advantages when having a lot of interrelated and duplicated data; not sure if chat would be like that, that most problematic thing would be... I don't know... avatar or username change?

@jonahbenton: finally ty

hey @jaen can you say more? to my eyes the complexity in this problem space- what slack has solved incredibly well- comes in the need for the client to be able to catch up with what's happened on the server, both when the client has been disconnected, and when the user wants to switch contexts (rooms)- and to do so in a way that is elegantly decoupled from the UI, while being sensitive to the greatly varied client platforms on which it's running and network throughput available at the moment. to me that speaks to a dataflow architecture, with a client-local data store, synchronization between which and server can be tailored to the client and network characteristics (e.g. be able to synchronize multiple rooms on more capable clients and optimize for one room on less).

+1 for datascript, have used it recently for a few projects (with om.next); Braid was started before that, but datascript is in the plans

@jonahbenton: sure, but as long as the messages are simple this is no harder to do with atoms IMO. It's only when the data gets complex - say, you have a user and some types of data related to that where you need to display the user as well the advantages of datascript become apparent. With plain atoms you will have a denormalised view of data and when something like "user changes the username" happens, you'd have to go and update it in all the places it is used in. With datascript this is all normalised so you have to update it only once and rely on relations to get the user.

But in general I agree that doing it the datascript is really powerful; heck, even my thesis is exactly about that.

It's just that writing it this way generically, with automatic synchronisation and such is somewhat involved and if chat would be simple enough to not benefit that much from being able to denormalise, query and simply update data

It probably would would make more sense to just use atoms and simple datastructures.

imo this is the most on fleek vision I've seen so far https://github.com/braidchat/braid/wiki/Motivation

Two demerits for ‘on fleek’. ¬_¬

Hahaha.

braid looks quite interesting, by the way.

had to look up 'on fleek'

@jaen sure, yeah- the empirical question is around how simple chat is, and what use cases matter for people to be able to dogfood. atoms and simple data structures are certainly fine for the case where everyone is connected and seeing updates live and on a good network. a client-side data model, likely supporting local storage, becomes more relevant for harder cases involving catchup, context switch, network blips. in either case, ensuring the ux is decoupled from the data model would be useful. what's your thesis? is it online?

@jonahbenton: Not online ATM, need to finish it first : V It's a engineering project thesis, so I'm not sure if it's all that interesting. The title is "Library for automatic synchronisation of state between a Single Page Application client and a server-side database" and it's basically what it says on the tin - I'm trying to figure out how to write a somewhat automated library to sync datascript at front with whatever at back and expose that to a reagent app with re-frame like event loop.

great topic! are you considering or basing it on any specific prior work?

Well, I've gotten the idea from reading tonksy's blogposts ~year ago when working on some project. It was supposed to be a file upload platform and I thought all these files, folders, users and such would be rather complex to handle with just update-in. So I decided to use datascript with something inspired by re-frame to handle events. It wasn't half-bad if unpolished. So when I had to decide on thesis topic I though I could use that idea.

There's certainly some inspiration coming from reading about Relay/GraphQL as well.

Not sure if om.next was around back then (I don't think so though, at least not as publicly), but when I first heard about it I was all like "hey, that's similar to what I wanted to do" and I thought it's pretty cool, since I agreed that this way of writing applications seems really sensible.

no, om.next didn't exist until maybe November I think

And it wasn’t even really ready to be played around with until maybe a month ago.

Ok, so it must have existed in february/march, but I don't think I was aware of it yet. (or you mean November 2015 in which case I think I've seen it around somewhat earlier)

And this is precisely why I suggested folks setup a test Slack and actually try out the various IRC bridge projects rather than continuing to discuss them in the abstract! https://clojurians.slack.com/archives/community-development/p1452405357000840

I can't believe there have been over 500 messages since I last checked in last night!

We fierce.

"That's some bad bikeshed, Harry!" to misquote a well-known TV production company.

Hah! Nice reference.

At the risk of adding yet more 'stuff people have to read' should we set up some kind of task board (Trello?) for tasks/stories for features for clojurians-chat?

The hope was that the linked Hackpads could serve that purpose 😛

This is what a MBaaS such as Firebase will give you essentially for free. https://clojurians.slack.com/archives/community-development/p1452443255001403

Possibly, but a) vendor lock-in, b) additional costs.

likely no to firebase - would have to work hard to convince me

just imo

I'm spending 98% of my time focusing on fleshing out the concept for this app

just fyi

anyone with a compelling concept should ping me

hopefully this is getting some attention: https://hackpad.com/collection/wnikaeBENEE

someone should write a pinable msg re how to work with that hackpad stuff

haven't had time to review it yet

Already done. Top link, contributing

cool, tyvm

and old wiki - did all get moved? should we delete old wiki or leave?

Everything with meaningful content as of last night got moved. I didn't delete anything.

did the braid page get moved

my page

meh - screw my page - not important at this point

no Braid didn't make it

please

and thank you

@meow: Concept in what sense?

would love to see alternate visions

if someone is so inclined

otherwise, spending lots of time dogfooding that system

needs work, not ready for more users yet - soon

Was going to suggest http://www.martinklepsch.org/chaf.html (again) but seeing it's linked there already

I should flesh this page out a bit more

Then maybe it becomes more useful in conversation

@martinklepsch: need to get you on the system asap so you can see for yourself - can we do that @rafd ?

rafd has stuff going on I know - today is not the best day, but maybe we can get the ball rolling to get you on there martin

From HN, here’s the equivalent discussion around XMPP: https://news.ycombinator.com/item?id=10387842

I’m going to have to back out of this a bit due to family/work time constraints, but one thing I was thinking about re: matrix - I’d worry that it introduces unnecessary complexity since we don’t need decentralisation/federation for this.

If that’s hidden by the standard implementations then great, if we’re implementing matrix ourselves that might be an issue.