Home

New Home: [HackPad] (https://hackpad.com/collection/wnikaeBENEE)

Do not update this wiki any more as it has been moved to the new home listed above.

---

All Clojurians are welcome to participate in the development of a chat app to help mitigate the risk of no longer being able to use Slack: Slackpocalypse

What is this?

This will become the ultimate chat platform for the clojure community, built by the clojure community. Not only do we want to provide a realtime chat platform, we want to showcase the ecosystem and the tools this language has to offer.

Why?

The Case Against Slack:

• Slack is proprietary and closed
• Slack is a for-profit company controlled by the whims of its investors
• Slack-the-company has declared they do not intend to support OSS communities as a valid use-case
• Thus, it is possible/likely that Slack will change their terms of use in the future in ways which make large OSS communities on the platform untenable
• Slack's current free plan only allows access to the most recent 10k messages. Due to the size of the community this is about a day's messages right now, and presumably this will get worse over time. Various archiving hacks exist, but they're currently a violation of the Slack ToS and put the whole community at risk of being shut down. They also can't archive private conversations.
• ???

The Case For Inventing Our Own Wheel:

• The Clojurians are clever and passionate people.
• The world could do with a (or indeed several) truly OSS Slack clone.
• A Clojure-based Slack clone would be:
  • An excellent showcase of the power of the language
  • A great tool for building the Clojurians community as it builds its own platform

The Devil's advocate against inventing our own wheel:

• It's a big project and we're all very busy.
• There are reasonable OSS options we could self-host (Mattermost, Zulip), they're just not clj(s)

Who?

If you feel like you have a stake in this effort please add your name to this list so we know that you feel this way. This doesn't imply a commitment or seniority or anything other than that you are involved and want to be kept in the loop. If you also have time to help out, even better. But serious interest is enough.

• adulteratedjedi
• cfleming
• mfikes
• pkobrien
• seancorfield
• shanekilkelly
• chrishowejones
• donmullen
• lfn3 (Liam)
• jaredly
• arrdem
• [johanatan] (https://github.com/johanatan)
• [mitchelkuijpers] (https://github.com/mitchelkuijpers)
• [gtrak] (https://github.com/gtrak)
• [plexus] (https://github.com/plexus)
• thomasmatecki
• you... ?

What?

An open-source chat application built in Clojure(script), as a replacement for Slack and other such proprietary platforms.

Goals

• Slack-alike functionality
  • Organisation/channel based chat rooms.
  • Direct messages
  • Avatars
  • Emoji
  • Reactji
  • File uploads
  • Code highlighting
  • Easy signup workflow
  • Smart-links (should inline gifs if a gif link is pasted, smart previews of linked articles)
  • Search (ideally full-text clever search of entire archive)
  • Image support
  • Notifications
  • Integrations (git, etc)
• Able to support at least 5k users without falling over
• Must provide complete archive of activity
• Mobile-friendly layout
• Should be scriptable/botable
• Easily deployable (should be possible to have a one-click-install button like on Digital Ocean)
• ???

Nice-to-haves

• Mobile clients (arguable should be in the main goals)
• Reactji Performance Art (see pkobrien for examples)
• Identicons or similar so people without custom avatars can still be easily distinguished
• ???

Practical Considerations

• Performance
  • If this app brings a phone browser to a grinding halt, it's not going to work out
  • ditto for the server, ideally it should be possible to deploy on a $5 Digital Ocean VPS (I think this is unnecessarily restrictive - cfleming)

Where?

The Internet.

When?

April 15 at Clojure/west 2016 would be a nice target date for having something, even just a demo.

How?

Tech

Clojure on the server, Clojurescript on the client. All other technologies should be chosen on their ability to meet a particular need of the project. Our tech stack should be as simple as it can be, while being as complex as big as it needs to be. We should refrain from throwing a technology/library into the stack "just because".

Whether it should use datomic is an open question due to licensing.

Organisation

???