I want to setup a trivia bot and while I know there are many other bots around ( Eggbot, various Python bots, Nerfbendr's Trivia Bot ), I want to do it for learning purposes too so I understand the protocol.
To save some time for myself, can anyone point out what differences there are between the various networks like Freenode, Efnet, Gamesurge? Do they all follow some standard protocol or do I have to branch out my commands per each network?
The basic IRC protocol (RFC 1459) is the same for all the networks.
Differences only appear when you get into things like nickname/channel registration, operator levels, services etc.
If your bot only sends and listens to messages, you will be fine if you only consider the IRC protocol. If you want it to interact with services and the like, you will have to see what each network you want to support uses and go from there.
All those network should (and i believe they do) follow the IRC RFC. So no, you should not need to program your bot for each network separately.
Related
My company has started looking into using a platform to generate chat bots, we came across microsoft's framework and are considering using it. we have a few concerns that we need to understand better about their product and would appreciate it if you could help us.
1) What kind of support do they give us when using Facebook messenger compared to what facebook gives natively? things like quick answer or image sending, buttons on the messages? do they support any of that?
2) We would like if you could elaborate exactly what the platform may give us and why we should use it, what we need is to keep all our logic in our servers and have a platform that will interact with all the messengers for us and keep us from coding to each a different code.
3) like question 1 but for telegram and any other messenger? (custom keyboards and stuff like that).
thanks for the help!
Thanks #ejadib
Regarding your second question, your bots logic does stay within your bot and your servers. The Bot Framework provides three things:
1) Connectivity services between your bot and the channels your users are on. All of the logic continues to reside in your bot.
2) Optionally - Bot Building SDK's you can use to facilitate dialog within your bot. These are SDK's you would code to, but still deploy to your own servers.
3) A directory where you could optionally publish your bot.
As #ejadib says, where we can be consistent across channels we add functionality to the core API; and where functionality is very specific to a channel we expose it through the ChannelData property of the C# SDK (SourceEvent in Node).
Regarding 1 and 3, if you want to be able to take advantage of special features or concepts for a channel (Facebook/Telegram) BotFramework provide a way for you to send native metadata to that channel giving you much deeper control over how your bot interacts on a channel. The way you do this is to pass extra properties via the ChannelData property (in C#).
Some things are already supported in the framework, for example Rich Cards will render differently depending on the channel.
Here you will find the information (including Facebook and Telegram).
Also, here you can find how for example you can use things like quick replies.
I have a scenario that i'd like to implement, and don't know where to begin.
I'd like to have 3 participants on a phone call: A, B and C.
A and C should be able to talk to and hear each other.
B should be able to hear A, but not C. B doesn't need to speak to anyone
Is there a way that I can implement this with SIP servers, freeswitch, asterisk or online services such as twilio/tropo?
Is there a name for such a scenario in telephony where you isolate the voices of one or more callers?
Thanks
It is known as call barge and is used in monitoring call center agents.
You can do it using the asterisk ChanSpy command:
http://www.voip-info.org/wiki/view/Asterisk+cmd+ChanSpy
in FreeSWITCH, eavesdropping works for the whole conversation. But as it's an open-source tool, you can probably modify sources for your needs.
You can develop a conferencing application using Call Control XML (CCXML). When you bring a caller on the conference you use the "join" element. When you "join" the caller you can specify in the "duplex" tag whether it is full or half. If it is half then the caller can only hear what is going on and cannot speak.
A great platform for trying this out for free is Voxeo's Prophecy. They have an excellent implementation of CCXML (their CTO is the Editor in Chief for this W3C standard) and you can try this hosted platform for free. You only pay when you put it into production. It supports SIP, Skype, and regular telephone lines. You can even use their Phono plugin to create a phone in a web browser that users could use to join the conference. They also have an on-premise solution that is easy to install on a laptop or server and they give you two ports for free. Additional ports are reasonably priced. There are a lot of examples on developing CCXML conferencing applications in their documentation.
try ivrworx,
you can firstly create freeswitch conference.
Thean make scripts which will call the conference but C will send SDP with rcvonly attribute
I'm currently integrating Sendgrid (Back-end API) with Phplist (front-end). However, I realised that there are many features that Phplist doesn't support such as autoresponders, different management levels (sub/superusers) and is unable to send high volumes. May I know if there is a better front end that I can use to integrate it with sendgrid?
Yes! OpenEMM seems to have the features you're looking for. You can see the full list here, but the highlights are:
Configuration of different users with different rights/roles
Autoresponder mails and error messages (bounce management)
It looks a little tricky to setup, but they have good documentation. Also, the code is hosted on SourceForge and the reviews look solid too.
In terms of setting it up with SendGrid, you have to configure your sendmail to use our SMTP servers. Luckily, we have a tutorial already that shows you exactly how to do that:
http://docs.sendgrid.com/documentation/get-started/integrate/examples/sendmail/
I am looking for a way to link IRC to Google Talk.
At the moment we use Partychatapp for google talk and we'd like to find a way to migrate to using IRC.
The vision is to have everyone in an IRC room and we'd be able to have a google talk bot people could use to talk to the room.
Does anything like this exist?
You want bitlbee. It looks like an IRC server to IRC clients and gateways to other IM protocols.
I wrote an application that does exactly this: https://github.com/PaulFreund/I2X
Multiple Users use it on a daily base and there are Ideas to expand it further.
At the moment it logs on to a XMPP account and to an IRC channel, and translates between the two. It works as-is without problems but could be better, if there were more users I probably had more interrest in developing it further.
I played with bitlbee a few years ago. Unless it's changed, it's not actually an IRC server, it just pretends to be one. It provides an irc-flavored proxy to the jabber server, so you can use your favorite IRC client to connect to a jabber server via bitlbee.
I understand that XMPP is used in chat services, but it seems to be more generally useful than that. Can someone list some scenarios and examples where you would consider using XMPP, and the pros and cons of it versus other approaches?
I know that Dropbox uses it for its filesharing system in Android (possibly it does in other platforms too).
Cons: much more verbose than binary (more bandwidth).
Pros: a wide variety of already implemented client and servers. A wide range of already implemented reliability, scalability, security, presence, rpc, federation, custom components, mail, VoIP mechanisms... the list is very very long. Even if you need something different, and you know where to touch, you could extend it to your needs, inheriting all the already implemented features.
We had a project on collecting information eg. wind direction, temperature, stock and forex, etc. Every sensor is a Jabber 'user'.
This allows us to detect if a sensor
is online, offline or problematic.
Sensors also publish information to
a pubsub node to be distributed to
collectors.
Human users can also
interact with a particular sensor by
querying with the sensor. The sensor
returns human friendly formatted
data.
We use it for chatrooms, and for distributing sports results to users watching live events.
Google Buzz and Facebook talk is built on it.