There are more and more people using Status instead of Slack now.
With that, there is higher and higher demand of making different kinds of automation for it.
One example might be:
an archival bot;
a bot that can send an automated message using Zapier or something else;
link unfurl bot that replies with title of the webpage to the posted link.
We had some efforts before to build some basic bots for Status:
I think it is the right time for us to push on this effort a bit to both make ourself (and out processes) comfortable in Status and also to help spreading the ecosystem.
I would like to understand:
what automation/integration do you want to have in Status?
who wants to join me and to create a swarm that will make these bots a reality?
UPD (10/10/18)
Bots
Historian — searchable history of Status channels, later integrated with Slack archives too;
Zapier integration to post messages to Slack from Zapier;
We had this problem for analytics purposes, i.e. we wanted to calculate which public chats are the most active and also unique participants of those chats.
My problem with status-go-sdk was that it’s very hard to debug and requires a Status node running along. It also uses JSON-RPC calls everywhere where native Go code could be used. This can be a benchmark of our status protocol where the same protocol is implemented in Clojure and Go. This can actually motivate us to write down this protocol, at least that part required to interact with public chats.
Actually, yesterday I talked about a very similar idea with @jonathan and we think it could be a great idea for https://hackathon.status.im/. We can form a team and write a bit more sophisticated bot (I liked that kudos bot).
I sure can do that, but I think then we need an example bot first. These links that I mentioned aren’t there yet. Maybe we can set this example on a hackathon, yes.
I was planning to start with at least an archival bot + search history next week-ish, because we really would need that.
@adam yeah, status-go-sdk was a first attempt to somehow extract the protocol/bot functionality, so bots can be written in Go. It requires a separate go node right now, that is true, but it was mostly because we couldn’t have status-go as a dependency, because of patches issue that you’ve solved.
I agree that we need an example first, I agree bounties are great @oskarth ; but without documentation / examples, there’s a big chance they’ll end up in a bounty graveyard like many of the ad hoc bounties in status-react happened but it won’t hurt to try. There was a really good example set in embark on how to tackle bounties (campaign around a set of issues), iuri brought up the point of less issues at once (eg. Something like focusing on 5 good issues at a time per repo is plenty) is probably best and they’ll uncover plenty of insights.
@igor really excited to see first iterations of this; would eventually like to see something like pro-bot functionality in slack (eg. ping you in status when a relevant repository / issue is worked on)
Communication is part of of our work output that’s getting lost - a searchable archive would be a top contender on my list. A MVP would be JSON exporting to an ELK running somewhere, though I’m sure there are fancier options out there.
A bonus would be to combine it with the slack archive so as to provide continuity.
Thanks a lot for your responses! I agree with @arnetheduck that the archival bot is definitely the first on the list. I will try to do something before the hackathon and then we can iterate from there. @adam do you want to participate in this first iteration (at least as a reviewer)?
Just noticed today that Probot had stopped working due to the fact that I deactivated my Slack account and therefore invalidated the access token. Eventually, we’ll need some sort of API that we can use from node.js.
hey @igor, in the last weeks I started something similar, I can try to publish it in the next days so that we can use it as a starting point if you want
@gravityblast@igor it would be great if you guys can share some details about your approach. As experimenting and looking from different angles is highly encouraged, I believe that at some point we should present a consistent narrative so that the audience of our work/tutorials and contributors are not lost.
Yes, 100% tutorials and examples are the critical thing here, we can’t (and we shouldn’t) do everything ourselves. What do you think about having a call on Monday to discuss how we want to proceed? @gravityblast@adam
Nope, there weren’t any progress since Prague.
But I agree that these responsibilities have not been assigned anywhere. I don’t have a good answer about what to do about these exactly in the new org.
@oskarth@naghdy do you have any idea where these kinds of tasks (that are definitely beneficial for our own project, but also might be beneficial to the community of Status users) should be?