There is some hype about DeFi and it goes basically to Ethereum
(I have not seen yet other non-Ethereum blockchain that prmote DeFi term usage).
Then there is MetaMask that is essential a wallet distributed as Chrome browser plugin.
But some blockchain site specifically require MetaMask and establish some communication between.
I know Ethereum, but it is blockchain and basically backend technology.
I think is has nothing to do with browsers and websites.
What exactly (technically speaking) is Ethereum blockchain enabled website?
Or other way round, how exactly MetaMask is to interact with website visited?
How websites interact with the MetaMask extension
Metamask extension injects the ethereum property into the JS window object. This property links to the JS API of the Metamask extension, allowing the website some level of control - such as "open a window requesting the user to submit this transaction" (but not "get the private key" for example).
This example JS code opens the Metamask window and asks the user for permission to share their (public) addresses with the website, when the myBtn is clicked. The shared addresses are then saved into the accounts variable.
$('#myBtn').click(async (e) => {
let accounts = await window.ethereum.request({
'method': 'eth_requestAccounts'
});
}
You can find more info at https://docs.metamask.io/guide/getting-started.html#getting-started
Basically in a decentralised application (DApp) the HTML frontend directly interacts with the blockchain without going through a web server. This is done with a wallet, existing independently from the DApp, confirms all the transactions. Any sent transaction goes directly from the frontend to the Ethereum blockchain through a JSON-RPC API node (see link for the request round trip description).
The main differences to the centralised web applications using server-side backend
The backend developer cannot break the terms of the (smart) contract, e.g. steal users money into his own pocket. This is called non-custodial model and it mitigates counterparty risk.
Backend cannot pull money or make user to do something they cannot accept, because wallet confirms all the transaction. Users, or their sophisticated representatives, can double check all smart contracts the wallet is going to interact on a blockchain.
Blockchain never goes down, unlike centralised services, because it is highly distributed (10,000 nodes)
User pays for all the transaction themselves using ETH as the currency for the transaction fees.
Note that the model is not exclusive to Ethereum, but also used by many other blockchains. Live DeFi applications can be found e.g. on EOS, Solana and NEAR blockchains and many Ethereum Virtual Machine compatible chains like Polygon, Avalanche and Binance Smart Chain.
Note that currently most users still need to trust the HTML code downloaded from some centralised web server. We have seen e.g. DNS takeover attacks in the past. However, this still greatly reduces the risk, as any "sign-in" to a web application does not automatically put the user in risk, as wallets still need to confirm any transaction.
Also note that blockchain makes little sense for applications that do not involve financial assets or other assets with value, like NFTs, because the main use case of a blockchain is to solve financial sovereignty and eliminate counterparty risk. This tradeoff comes with high transaction costs and the need of some sort of cryptocurrency.
Related
We want to use ejabberd in the context of a web application having fairly unique and business rules, we'd therefore need to have every chat message (not protocol message, but message a user sends to another one) go through our web application first, and then have the web application deliver the message to ejabberd on behalf of the user (if our business rules allow the message to be sent).
The web application is also the one providing the contact lists (called rosters if I understand correctly to ejabberd). We need to be and remain the single source of truth to ease maintenance.
To us, ejabberd value added would be to deliver chat messages in near real-time to clients, and enable cool things such as presence indicators. Web clients will maintain a direct connection to ejabberd through websocket, but this connection will have to be read-only as far as chat messages are concerned, and read-write as far as presence messages are concerned.
The situation is similar with regards to audio and video calls. While this time the call per see will directly be managed by ejabberd to take advantage of built-in STURN, TURN etc... and will not need to go through our web app, we have custom business logic to manage who is able to call who, when, how often etc... (so in order words, we have custom business logic to authorize the call or not and we'd like to keep all the business logic centralized in the web app).
My question is what would be the proper hooks we'd need to look into to achieve what we are after? I spent an hour or so in the documentation, but I couldn't find what I am after so hopefully someone can provide me pointers. In an ideal world, we'd like to expose API endpoints from our web app that ejabberd hooks can hit. However, the first question is: which relevant hooks is ejabberd offering and where are these hooks documented?
Any help would be greatly appreciated, thank you!
When a client sends a packet to ejabberd, it triggers the user_send_packet hook, providing the packet and the state of the client's session process. Several modules use that hook, for example mod_service_log.
I want to deploy a smart contract on server and interact with it using mobile client. I'm not familiar with how does that work but after some research, I found something like below:
If we compare communication through web services in mobile client, then pretty much everything is same expect in Smart contract, is no database or deployment service as the result of decentralized nature of the system. Is that right? We can connect mobile client to smart contract using some library like web3 which would essentially work with Json RPC or websockets.
But what if I don't want to connect each mobile client to smart contract using library like web3? Instead, what if I want to have a HTTP server and then it would connect to smart contract like below?
Is that possible? If yes, then how can I do that?
My second question is regarding deployment. In the centralized server scenario, I would have database deployed on some service like AWS etc. I could estimate the deployment cost. I understood that we have to deploy smart contract on Ethereum mainnet which will cost some x amount of Ether. But then I found out that my users will have to pay for each computation. What if I want to bear all the costs? How can we estimate such costs?
Instead, what if I want to have a HTTP server and then it would connect to smart contract like below?
You certainly can do this, some might argue a layer of centralization is added by placing a web server between the DApp and blockchain, but I would disagree. If you want to do this, your DApp would simply call a REST API on your web server which in return would utilize web3.js (node.js), web3j (Java), Nethereum (C#/.NET) or any other flavor of Web3 to interact directly with the blockchain.
What if I want to bear all the costs?
You will only be able to bear the costs of deploying smart contracts which are deployed on your behalf and not on behalf of any potential end-users.
How can we estimate such costs?
You can estimate the gas cost of a contract deployment or contract interaction via web3's estimateGas method. Understand, this cost can be largely effected by how well structured your Solidity smart contract code is written. Note, this is of course also only an estimate as users could always expend more Ether to have their transaction confirmed quicker or the state of the data within the smart contract could change over time requiring higher gas costs (i.e. iterating a growing array). For more information on gas costs within the Ethereum mainnet, you can take a look at ETH Gas Station.
As a side note, since I do not know your particular use case for blockchain technology, it could be helpful to weigh out whether or not it makes sense to utilize the Ethereum mainnet or to spin up your own private Ethereum blockchain. With the latter you would completely avoid having to spend any Ether to interact with blockchain network, but you would likely have additional overhead.
I am new to Ethereum, Blockchain Technology.I have been going through Tutorials on Ethereum and Smart Cotracts.
As per my Understanding, If we want to make any change to data members of the smart contact, it ll cost us some Ether right ? so , i am wondering how Free chat DApps work?. I mean, it should cost ether for storing the data of chats and transaction of data right ? or are they using any test networks such as kovan,rinkeby ?
Thanks in Advance
In addition to other answer, I don't think so your referenced Apps are using Ethereum blockchain to save chat messages as it always requires Gas to add anything in a public Ethereum blockchain network. To integrate chatting in your App you can use XMPP Framework.
Obviously you require to have a centralized server (Against the blockchain basic terminology) But chat history is not required to save on the server. It can only be saved on Users Device and can use end-to-end encryption. Server will only be required to implement socket-based communication by using XMPP framework. Or you can also use Firebase Realtime Database for a chat. But I totally agree it's against the basic blockchain rule of decentralization.
If you are using the public Ethereum blockchain it costs Ether to change data. It costs money to get these Ether so a Free chat on this network seems unlikely.
If you are using someone's private Ethereum blockchain it costs Ether to change data, but Ether has no value and can be given more or less easily (like Rinkeby).
If you are using your private Ethereum blockchain it costs Ether to change data, but you can get Ether easily at genesis block or mining Ether.
If you are using a private Ethereum blockchain like Quorum with GasPrice=0, you don't need Ether.
I am currently working on a REST/JSON API that has to provide some services through remote websites. I do not know the end-customers of these websites and they would/should not have an account on the API server. The only accounts existent on the API server would be the accounts identifying the websites. Since this is all RESTful and therefore all communication would be between end-user browser (through javascript/JSON) and my REST API service, how can I make sure that the system won't be abused by 3rd parties interested in increasing the middleman's bill? (where the middleman is the owner of the website reselling my services). What authentication methods would you recommend that would work and would prevent users from just taking the js code from the website and call it 1000000 times just to bankrupt the website owner? I was thinking of using the HTTP_REFERER , and translate that to IP address (to find out which server is hosting the code, and authenticate based on this IP), but I presume the HTTP_REFERER can easily be spoofed. I'm not looking for my customer's end customers to register on the API server, this would defeat the purpose of this API.
Some ideas please?
Thanks,
Dan
This might not be an option for you, but what I've done before in this case is to make a proxy on top of the REST calls. The website calls its own internal service and then that service calls your REST calls. The advantage is that, like you said, no one can hit your REST calls directly or try to spoof calls.
Failing that, you could implement an authentication scheme like HMAC (http://en.wikipedia.org/wiki/Hash-based_message_authentication_code). I've seen a lot of APIs use this.
Using HMAC-SHA1 for API authentication - how to store the client password securely?
Here is what Java code might look like to authenticate: http://support.ooyala.com/developers/documentation/api/signature_java.html
Either way I think you'll have to do some work server side. Otherwise people might be able to reverse engineer the API if everything is purely client side.
I would like to learn what are the scenarios/usecases/ where messaging like RabbitMQ can help consumer web applications.
Are there any specific resources to learn from?
What web applications currently are making use of such messaging schemes and how?
In general, a message bus (such as RabbitMQ, but not limited to) allows for a reliable queue of job processing.
What this means to you in terms of a web application is the ability to scale your app as demand grows and to keep your UI quick and responsive.
Instead of forcing the user to wait while a job is processed they can request a job to be processed (for example, clicking a button on a web page to begin transcoding a video file on your server) which sends a message to your bus, let's the backend service pick it up when it's turn in the queue comes up, and maybe notify the user that work has/will begin. You can then return control to the UI, so the user can continue working with the application.
In this situation, your web interface does zero heavy lifting, instead just giving the user visibility into stages of the process as you see fit (for example, the job could incrementally update database records with the state of process which you can query and display to your user).
I would assume that any web application that experiences any kind of considerable traffic would have this type of infrastructure. While there are downsides (network glitches could potentially disrupt message delivery, more complex infrastructure, etc.) the advantages of scaling your backend become increasingly evident. If you're using cloud services this type of infrastructure makes it trivial to add additional message handlers to process your jobs by subscribing to the job queue and just picking off messages to process.
I just did a Google search and came up with the following:
Reddit.com
Digg.com
Poppen.De
That should get you started, at least.