We're building a frontend for Hydra Wallet to help with wallet creation and management. One issue we ran into is understanding the edge cases of membership models other than the Wallet membership model as well as how the wallet works with tokens.
Let's say we create a wallet:
const { fanout } = await fanoutSdk.initializeFanout({
name: `Test#${Date.now()}`,
membershipModel: MembershipModel.Wallet,
totalShares: 100,
});
After that, we initialize the wallet for accepting certain SPL tokens, multiple times with different tokens:
await fanoutSdk.initializeFanoutForMint({ fanout, mint1 });
await fanoutSdk.initializeFanoutForMint({ fanout, mint2 });
await fanoutSdk.initializeFanoutForMint({ fanout, mint3 });
Will the fanout wallet accept all three types of tokens or just the last one?
What happens if, let's say, there were already tokens of the first type owned by the wallet when the second call was made?
I think - I am not 100% sure though - that you should be able to use it with all three mints that you initialised.
The initialisation creates the necessary accounts for it to work. When distributing you will obviously have to run the call for each token.
To be save you should test this in devnet though. It’s done quite fast since you can just create and mint three different random spl tokens.
Related
Try to transfer tokens to one of the account declared in remaining_accounts list.
Here's the way I create CpiContext:
let cpi_context = CpiContext::new(ctx.accounts.token_program.to_account_info(),
Transfer {
from: ctx.accounts.account_x.to_account_info(),
to: ctx.remaining_accounts.first().unwrap().to_account_info(),
authority: ctx.accounts.owner.to_account_info().clone()
});
I got error related to CpiContext lifetime mismatch. Exact log error: lifetime mismatch ...but data from ctx flows into ctx here.
Why I want to use remaining accounts to transfer tokens? This transfer is optional depending on whether user decides to pass the account (referral links/affiliation). Other methods than passing account as remaining accounts to implement the optional transfer will be also highly appreciated.
Make sure that you help out Rust's lifetime inference in your instruction:
pub fn your_instruction<'info>(ctx: Context<'_, '_, '_, 'info, YourContext<'info>>, ...)
I have a NEAR application in which most of the methods do not transfer any tokens. Users go through the standard login flow with NEAR wallet, have their 0.25N allowance for gas, and then interact with the application.
I now have a new end-point that I want to be callable from the front-end, which expects the user to pay an amount significantly exceeding 0.25N:
#[payable]
pub fn buy_stuff() {
When I use the standard near-api-js way to call it:
window.contract.buy_stuff({}, undefined, price).then(m => window.location.href='/');
it fails, because it tries to spend the price from the allowance of the aceess key logged in, which it doesn't have -- it naturally only has 0.25N it has for gas.
The specific error is "Access Key {account_id}:{public_key} does not have enough balance 247864837491516400000000 for transaction costing 5004231023352653388973496"
What I want instead is to get the user redirected to the wallet, and authorize this particular transaction using their full access key in the wallet. Is there a way to do that with near-api-js?
It looks like the issue is that the contract API doesn't consider a wallet redirect. One reason might be the initialization of the contract API.
In order for a contract API to be able to redirect to a wallet, the initialization should be done with the ConnectedWalletAccount. It can be done using the following code:
const nearConnection = await nearAPI.connect(...);
const walletConnection = new nearAPI.WalletConnection(
nearConnection,
ContractName
);
const contract = new nearAPI.Contract(
walletConnection.account(),
ContractName,
{
viewMethods: [...],
changeMethods: [...],
}
);
I'm writing a new SPA application that will subscribes to several rooms for several types of information updates.
In my production setup I'll use two servers behind a load balancer for reliability.
In the event of disconnect - Does the client have to resend the request for rooms subscriptions on the reconnect event callback, or is there a way to have the server reconnect the client automatically (even when the client reconnects to a different server due to server failure) ?
Socket.io will unsubscribe your users from all rooms on a disconnect. It will unsubscribe you from the server side. I played around with this a little. The server can store your user's rooms in redis or a database under the user ID and, upon connecting, check to see if that user should be in any of these rooms. At which time your user can join them from the server side without ever having to do anything from the client.
The problem is that this list of rooms must be constantly stored and updated. It's just another thing that has to work seamlessly on the backend. It's a lot of tests to consider all the possibilities that could mess up your organization. Like, what if they log in on another device, you have to clear the rooms and put in new ones, but if the user opens his laptop again and it reconnects, now he has to get back in those rooms from his laptop. ...It's totally doable/solvable, but I only did this on the front end:
// rejoin if there's a disconnect
mySocket.on('reconnect', () => {
mySocket.emit('subscribe', 'theRoom')
})
...and no further hassle. If you added some more details about why it's necessary to do it from the server..?
From my experience, I found this to be the easiest and useful solution:
Client side:
// the next 3 functions will be fired automatically on a disconnect.
// the disconnect (the first function) is not required, but you know,
// you can use it make some other good stuff.
socket.on("disconnect", function() {
console.log("Disconnected");
});
socket.on("reconnect", function() {
// do not rejoin from here, since the socket.id token and/or rooms are still
// not available.
console.log("Reconnecting");
});
socket.on("connect", function() {
// thats the key line, now register to the room you want.
// info about the required rooms (if its not as simple as my
// example) could easily be reached via a DB connection. It worth it.
socket.emit("registerToRoom", $scope.user.phone);
});
Server side:
io.on('connection', function(socket){
socket.on("registerToRoom", function(userPhone) {
socket.join(userPhone);
});
});
And thats it. Very simple and straight forward.
You also can add in the connected socket (the last function) some more updates to the user display, such as refreshing its index or something else.
Socket.io does have a reconnect event - Docs here
Something like the below should work
socket.on('reconnect', () => attemptReconnection())
The attempt reconnection callback would look something like:
const attemptReconnection = () => socket.emit('joinRoom', roomId)
I'm looking to develop a chat application with Pubnub where I want to make sure all the chat messages that are send is been stored in the database and also want to send messages in chat.
I found out that I can use the Parse with pubnub to provide storage options, But I'm not sure how to setup those two in a way where the messages and images send in the chat are been stored in the database.
Anyone have done this before with pubnub and parse? Are there any other easy options available to use with pubnub instead of using parse?
Sutha,
What you are seeking is not a trivial solution unless you are talking about a limited number of end users. So I wouldn't say there are no "easy" solutions, but there are solutions.
The reason is your server would need to listen (subscribe) to every chat channel that is active and store the messages being sent into your database. Imagine your app scaling to 1 million users (doesn't even need to get that big, but that number should help you realize how this can get tricky to scale where several server instances are listening to channels in a non-overlapping manner or with overlap but using a server queue implementation and de-duping messages).
That said, yes, there are PubNub customers that have implemented such a solution - Parse not being the key to making this happen, by the way.
You have three basic options for implementing this:
Implement a solution that will allow many instances of your server to subscribe to all of the channels as they become active and store the messages as they come in. There are a lot of details to making this happen so if you are not up to this then this is not likely where you want to go.
There is a way to monitor all channels that become active or inactive with PubNub Presence webhooks (enable Presence on your keys). You would use this to keep a list of all channels that your server would use to pull history (enable Storage & Playback on your keys) from in an on-demand (not completely realtime) fashion.
For every channel that goes active or inactive, your server will receive these events via the REST call (and endpoint that you implement on your server - your Parse server in this case):
channel active: record "start chat" timetoken in your Parse db
channel inactive: record "end chat" timetoken in your Parse db
the inactive event is the kickoff for a process that uses start/end timetokens that you recorded for that channel to get history from for channel from PubNub: pubnub.history({channel: channelName, start:startTT, end:endTT})
you will need to iterate on this history call until you receive < 100 messages (100 is the max number of messages you can retrieve at a time)
as you retrieve these messages you will save them to your Parse db
New Presence Webhooks have been added:
We now have webhooks for all presence events: join, leave, timeout, state-change.
Finally, you could just save each message to Parse db on success of every pubnub.publish call. I am not a Parse expert and barely know all of its capabilities but I believe they have some sort or store local then sync to cloud db option (like StackMob when that was a product), but even if not, you will save msg to Parse cloud db directly.
The code would look something like this (not complete, likely errors, figure it out or ask PubNub support for details) in your JavaScript client (on the browser).
var pubnub = PUBNUB({
publish_key : your_pub_key,
subscribe_key : your_sub_key
});
var msg = ... // get the message form your UI text box or whatever
pubnub.publish({
// this is some variable you set up when you enter a chat room
channel: chat_channel,
message: msg
callback: function(event){
// DISCLAIMER: code pulled from [Parse example][4]
// but there are some object creation details
// left out here and msg object is not
// fully fleshed out in this sample code
var ChatMessage = Parse.Object.extend("ChatMessage");
var chatMsg = new ChatMessage();
chatMsg.set("message", msg);
chatMsg.set("user", uuid);
chatMsg.set("channel", chat_channel);
chatMsg.set("timetoken", event[2]);
// this ChatMessage object can be
// whatever you want it to be
chatMsg.save();
}
error: function (error) {
// Handle error here, like retry until success, for example
console.log(JSON.stringify(error));
}
});
You might even just store the entire set of publishes (on both ends of the conversation) based on time interval, number of publishes or size of total data but be careful because either user could exit the chat and the browser without notice and you will fail to save. So the per publish save is probably best practice if a bit noisy.
I hope you find one of these techniques as a means to get started in the right direction. There are details left out so I expect you will have follow up questions.
Just some other links that might be helpful:
http://blog.parse.com/learn/building-a-killer-webrtc-video-chat-app-using-pubnub-parse/
http://www.pubnub.com/blog/realtime-collaboration-sync-parse-api-pubnub/
https://www.pubnub.com/knowledge-base/discussion/293/how-do-i-publish-a-message-from-parse
And we have a PubNub Parse SDK, too. :)
I ran into this issue just recently when I wanted to test my app with multiple live ids. I have an Azure Mobile Service that I use the live id with. Basically I remember being asked for whether the app can use my credentials or not at least once. Now the LiveAuthClient CanLogout variable is always false so I can't log my account out in order to sign in with another account.
I found some reference saying that I would need to remove some single sign on stuff by hand, but I could only find one thing in Credential Manager that was seemingly similar and removing it (MicrosoftAccount:sth) had no effect. Here's the relevant piece of my code:
LiveAuthClient liveIdClient = new LiveAuthClient("myserviceredirecturi");
LiveLoginResult liveAuthResult = await liveIdClient.InitializeAsync(new[] { "wl.basic" });
if (liveIdClient.CanLogout)
liveIdClient.Logout(); // Code never goes here, ever.
LiveLoginResult liveLoginResult = await liveIdClient.LoginAsync(new[] { "wl.basic" });
The last line logs me in with the current windows 8 live id. How can I test with multiple live ids?