Is it possible to communicate with Rainbow bridge via API from a smart contract from NEAR? Let's say I want to take NEAR, send it to a smart contract in NEAR blockchain. Then I want this smart contract to automatically send it through the bridge to Aurora, send to some contract, after some time, get money back and bridge back and send to the original user's wallet on NEAR
Currently, only NEP-141 tokens can be sent from NEAR to Aurora and back so what you mentioned would be possible with wNEAR.
General asynchronous communication between NEAR and Aurora is being developed. Discussions are underway about adding native NEAR support inside of Aurora: https://github.com/aurora-is-near/rainbow-bridge/discussions/642.
Related
I am designing a whatsapp like messenger application for the desktop using WPF and .Net. Now, when a user creates a group I want other members of the group to receive a notification that they were added to a group. My frontend is built in C#.Net, which is connected to a RESTful Webservice (Ruby on Rails). I am using Postgres for the database. I also have a Redis layer to cache my rails models.
I am considering the following options.
1) Use Postgres's inbuilt NOTIFY/LISTEN mechanism which the clients can subscribe to directly. I foresee two issues here
i) Postgres might not be able to handle 10000's of clients subscribed directly.
ii) There is no guarantee of delivery if the client is disconnected
2) Use Redis' Pub/Sub mechanism to which the clients can subscribe. I am still concerned with no guarantee of delivery here.
3) Use a messaging queue like RabbitMQ. The producer of this queue will be postgres which will push in messages through triggers. The consumer of-course will be the .Net clients.
So far, I am inclined to use the 3rd option.
Does anyone have any suggestions how to design this?
In an application like WhatsApp itself, the client running in your phone is an integral part of a large and complex event-based, distributed system.
Without more context, it would be impossible to point in the right direction. That said:
For option 1: You seem to imply that each client, as in a WhatsApp client, would directly (or through some web service) communicate with Postgres as an event bus, which is not sound and would not scale because you can only have ONE Postgres instance.
For option 2: You have the same problem that in option 1 with worse failure modes.
For option 3: RabbitMQ seems like a reasonable ally here. It is distributed in nature and scales well. As a matter of fact, it runs on erlang just as most of WhatsApp does. Using triggers inside Postgres to publish messages however does not make a lot of sense.
You need a message bus because you would have lots of updates to do in the background, not to directly connect your users to each other. As you said, clients can be offline.
Architecture is more about deferring decisions than taking them.
I suggest that you start simple. Build a small, monolithic, synchronous system first, pushing updates as persisted data to all the involved users. For example; In a group of n users, just write n records to a table. It is already complicated to reliably keep track of who has received and read what.
This heavy "group" updates can then be moved to long-running processes using RabbitMQ or the like, but a system with several thousand users can very well work without such thing, especially because a simple message from user A to user B would not need many writes.
I'm a PHP developer with a lack of experience on other sever side langages.
I’d like you to give me leads, advice, keywords or whatever that could help me refine my research better.
What I want to do is basically to create a one to one mobile app chat that will scale.
There will be channels of 3 users: User A, User B and the "computer" pushing some messages according to some channels informations like the last time a message has been sent, etc.
User A should know if User B is online, writing, etc.
Every conversation should be stored in a database and would be analyzed by some algorithms. Those algorithms would also analyzed stuffs on user Facebook open graph.
The application should be able to send notification on IOS and Android.
A web administration should allow admin to set some stuff that will define what kind of message would be sent by the "computer".
I'v read lot of posts about websocket, xmpp, node.js, socket.io, etc but I don't have enough knowledge in those areas to decide what architecture should I build to make everything works together. Or maybe there is some cloud base solutions that would fit my needs...
Thanks
As you've stated there are many ways to implement that kind of structure but I am going to write about node.js + socket.io part;
1) It is scalable. You can use cluster, nginx, haproxy. etc. to apply load balancing to your socket.io application (see here) Of course you've to use redis or mongo or some kind of store for socket.io that different servers and processes can communicate each other. (see here)
2) socket.io have rooms. That means clients and any computer bots can join that room to share events with each other. So, in your scenario User A, User B and a computer bot should join to same room and events sent to that room will be broadcasted to every room member. (events can vary as online, typing, new message, anything) (see here)
3) node.js can send push notifications both for iOS and Android.
4) You can write every message to database of your choice on new message event.
5) You can create a REST api with Express framework for your Administration page. And you can use passport for authentication and authorization purposes. You can consume the rest api with Jquery or some other frontend framework like React etc.
Meteor is very well suited for something like this and gives you everything you need. There are also open sourced chat systems built with meteor already to get an idea of where you need to go. The more custom route would be to do what #cdagli said.
I have a client company with a simple web application (Python Flask) and I need to add a phone notification functionality to it.
The main requirement is that the app should call users, play a certain sound file and accept some tone input ("Hello! This is an automated message from your WebApp account. You have a meeting with $John today at $5pm. Please press 1 to confirm").
The other requirement is that the solution should be relatively cheap and fast to market.
I have done some research already and it seems that there are a few consequent steps to achieve that:
Set up an Asterisk or a FreeSwitch server;
Set up a SIP account;
Write some business logic for the Asterisk server which allows to make calls and play sounds via a SIP account;
Write an API at the Asterisk server and expose it to the Python Flask web app.
Do I miss something here? Can any of the steps be omitted anyhow? Can I do it simpler?
the fastest way to get it working is to use one of the cloud voice services with speech synthesiser. Here's a short list to check out:
Twilio
Tropo
Plivo
Here I listed some details.
Those services charge you per minute, plus you may have to pay some monthly fee.
If you want to run an independent and standalone service, I would recommend FreeSWITCH instead of Asterisk. It's got reach integration possibilities and API. You will need to read the FreeSWITCH book in order to understand how it works and how to build your service.
I agree with Stanislav Sinyagin on the cloud based solutions, but I would add one more, Voxeo Prophecy. Tropo is from Voxeo, but they have offered Prophecy as a solution for a lot longer and it supports the open standards CCXML and VoiceXML. The advantage of CCXML for outbound notification applications is you have a lot more control of the notification process.
The Prophecy platform has excellent call progress analysis (CPA) which will allow you to determine whether a machine or a human answered and handle the call accordingly. For example, it does not make sense to ask a machine to "...press one to confirm". Instead you may want to leave a message that provides a call back number for the user to confirm with after they have listened to the voice message. The CPA can be used to leave a message on a machine at the correct time (when the greeting message has stopped) so that you do not get clipped messages in the voice mail. CPA will also allow you to provide detailed reports on who was notified and for those that did not it can tell you whether it was a bad number (received a SIT tone), a modem or fax answered, or ring-no-answer (pretty rare these days). These type of details can factor into your retry process for failed notifications.
The other advantage to using Prophecy and open standards is your application will be portable to other IVR systems that are VoiceXML/CCXML compatible if you ever want to migrate. Tropo, Twilio, and Plivo all use proprietary API's which does not allow you to move your applications to other services. Prophecy is also available as a software solution so that if you want to take it out of the cloud you can run it on premise. You can get a two port version for free to try it out.
There is excellent documentation on developing outbound notification systems on Voxeo's developer site. Take a look at the CCXML documentation in section F on Outbound Dialing.
Not sure which development languages you are familiar with, but if you are used to ASP.NET MVC there is an open source project called VoiceModel that makes it easier to develop VoiceXML applications. The other advantage of VoiceModel is that you develop your application once and it will run on any VoiceXML compatible platform and Tropo. They are currently working on adding outbound notification support in this project that will work for both Tropo and VoiceXML.
Third party solutions listed are your easy choice. Running your own asterisk is also suitable for what you want to do, but i think for only this much it would be overkill, from an operational perspective.
In asterisk, you can originate a call that has the 2 variables you need with an (basic-authenticated) HTTP request. You will also need some settings and a tiny dialplan. Setting up the SIP account is easier or more difficult, depending on the documentation from the provider. Most of them have detailed documentation for configuring asterisk (not so much so for freeswitch). Keeping the damn thing alive is what's gonna get to you :)
Is there a replacement technology for TAPI that supports third-party call control (3pcc)?
I want to provide the following 3pcc functionalities in an application:
Outgoing call:
User clicks at a button in the application.
The user's phone goes off hook, and the callee's phone rings.
The callee's phone shows the phone number of the callee, not the phone number used for the application.
When the callee picks up the phone, the connection is established.
Incoming call:
When user's phone rings, the caller's number and the called number are sent to the application.
The application evaluates the numbers and shows e.g. a customer record.
In the past, I would have done this with TAPI, but it seems that Microsoft does not actively develop TAPI any more (even though TAPI is supported with all current Windows versions, up to Windows 7). Therefore, I am searching for a technology that is more likely supported in the future by the majority of telephony system providers.
I am aware of CSTA, which could be used to do this, but this also is a pretty old technology and not very widespread (it has 100 times less Google hits than TAPI, for example).
I am also aware of SIP, which does not have direct support for 3pcc features, but there are ways to work around this:
For outgoing calls: use application's SIP endpoint to connect to the two phones first, then connect them by making a kind of "conference call".
For incoming calls: use SUBSCRIBE and NOTIFY and dialog event package.
Problem is that the procedure for outgoing calls is very clumsy, and the called phone would not display the correct phone number (i.e. the caller's number) when ringing.
Furthermore, SIP is not a single standard, but a collection of many different RFCs, and it seems that telephony system manufacturers only implement parts of those RFCs, and there usually is no good documentation which parts are implemented.
So, my question is: is there any other telephony integration standard that
supports third-party call control, and that can be considered as a widely supported standard in the foreseeable future?
I'd suggest you consider CSTA3.
ECMA CSTA3 is a comprehensive standard for 3rd party telephony call control far superior to TAPI in detail and implemented by several vendors. A web service definition exists for CSTA.
See ECMA CSTA 3
I can highly recommend the standard but would suggest you carefully consider if the target vendor supports the CSTA standard as you require.
The answer to the OP is yes. A couple years ago I was trying to do TAPI work and had all of the same issues as everyone else. Rather than using local hardware and drivers, I found cloud services which do everything requested in the OP. I won't mention a specific service unless someone PM's me. But my recommendation is to go off the standard path, and stop beating your head against the TAPI wall. HTH
stop beating your head against the TAPI wall
That would be nice. PM's are however not possible here TonyG. I would love hear about your cloud service experiences. Without getting specific, do you really mean call control over my desk phone is possible from the cloud?
Try Esna Ilink For Cisco Or Esna Ilink Pro. This product is Platform Independent and will work with any thing including TAPI and CSTA.
By looking at current Google wave APIs, I can't find a way to create an alternative client.
It's not a robot or gadget, and the embed API is very slim.
Nevertheless, I do see some clients out there - such as Waver and Waveboard.
How do they do it ? is it based on XMPP ?
Note that Waver and Waveboard aren't actual clients, rather single-application web-browsers wrapped around the official https://wave.google.com/wave/ URL.
The Wave Federation protocol comes with a Protocol Buffers based experimental client/server protocol. Some people are using that to make a client, but it's not yet interoperable with the existing wave infrastructure unless you set up your own server (it won't work with #googlewave.com users, you must set up your own wave federation server and have it communicate to that).
During Google I/O they announced the Google Wave Data API which allows a program to read and write to wave on behalf of a user using OAuth. I'm using it to create a true mobile client, but at the current state, it's still very limited and restricted to the actions of fetchWave, search and folderAction (markAsRead/Unread, mute and archive).
http://code.google.com/apis/wave/extensions/wavedataapi/index.html
Lars Rasmussen did mention the beginning of a public client/server protocol, but I can't yet find anything about it.