We provide technology backed solutions to companies that turn referrals into a primary hiring source and allow them to manage and grow their employees in a highly effective way

Real Links

At AISPEECH, we provide conversational AI services and natural language interaction solutions for a wide range of entities including financial institutions, the government, and IoV and IoT companies. If you believe in the idea that big data is the fuel for artificial intelligence, you will see how important a performant data processing architecture is for us. In this post, I am going to share with you what data tools and techniques we use to power our AI services. Real-Time vs. Offline: From Separation to Unity Before 2019, we used Apache Hive + Apache Kylin to build our offline data warehouse, and Apache Spark + MySQL for real-time analytic data warehouse: Roughly, we have three data sources: Business databases such as MySQL Application systems such as K8s container logs Automotive T-Box logs We write such data into Kafka via MQTT/HTTP protocol, business database Binlog, and Filebeat log collection. Then, the data will be diverted to two links: real-time and offline. : Data cached by Kafka will be computed by Spark and put into MySQL for further analysis. Real-time data link : Data cleaned by Kafka will be put into Hive. Then, we used Apache Kylin to create Cubes, but before that we needed to pre-construct a data model, which contains association tables, dimension tables, index fields, and relevant aggregation functions. Cube creation is triggered by a scheduling system on a regular basis. The created Cubes will be stored in HBase. Offline data link This architecture is a seamless integration with Hadoop technologies, and Apache Kylin delivered excellent performance in pre-computing, aggregation, exact deduplication, and high-concurrency scenarios. But as the days go by, some unpleasant issues reveal themselves: : Kylin 2.x and 3.x relies heavily on Hadoop and HBase. Too many components bring longer development links, higher instability, and more maintenance costs. Too many dependencies : This is a tedious process with all the flat table creation, column deduplication, and Cube creation. Every day, we ran 1000~2000 tasks but at least 10 of them failed so we had to spend a big chunk of time writing auto O&M scripts. Complicated Cube creation in Kylin : Dimension expansion means the prolonged creation time of Cubes when a data analysis model involves too many fields without data pruning; dictionary expansion happens when global exact deduplication takes too long and results in larger dictionaries and longer creation time. Both can drag down the overall data analytic performance. Dimension/dictionary expansion : Any changes in the computation fields or business scenarios could entail backtracking of data. Low flexibility of data analysis model : We were unable to query data breakdown with this architecture. A possible solution was to push these queries down to Presto, but the introduction of Presto would mean more O&M troubles. No support for breakdown queries So we started to find a new OLAP engine that could best serve our needs. Later, we narrowed down our choices to ClickHouse and Apache Doris. Due to the high O&M complexity, numerous table types, and lack of support for associated queries, we opted for Apache Doris in the end. In 2019, we built an Apache Doris-based data processing architecture, where both real-time and offline data will be poured into Apache Doris for analysis: We could have created an offline data warehouse in Apache Doris directly, but due to legacy reasons, it would be difficult to migrate all our data there, so we decided to preserve the upper half of our previous offline data link. What's different was that the offline data in Hive would then be written to Apache Doris instead of Apache Kylin. The Broker Load method of Doris was fast. Everyday, it took 10~20 minutes to ingest 100~200G data into Doris. As for the real-time data link, we used Doris-Spark-Connector to ingest data from Kafka to Doris. What's Good About the New Architecture? Deploying Apache Doris is easy since it only has Frontend and Backend processes. Both types of processes can be scaled out, so we can create only one cluster to handle hundreds of machines and dozens of PBs of data. We have been using Apache Doris for three years but only spent very little time on maintenance. Simple O&M with no dependencies on Hadoop components. Having a one-stop data warehouse that is capable of real-time data services, interactive data analysis, and offline data processing makes the development link short and simple. If anything goes wrong, we only need to check a few spots to find the root cause. Easy trouble shooting. This is similar to table association in MySQL. It is helpful in scenarios that require frequent change of data analysis models. Support for JOIN queries in Runtime format. Support for JOIN, aggregate, and breakdown queries. These include rollup index and materialized view. Rollup index allows us to implement secondary index to speed up queries. Support for multiple query acceleration methods. such as Hive, Iceberg, Hudi, and databases like MySQL and Elasticsearch. Support for federated queries across data lakes How Apache Doris Empowers AI In AISPEECH, we use Apache Doris in real-time data query and user-defined conversational data analytics. Real-Time Data Query The real-time data processing pipeline works as above. We ingest offline data via Broker Load, and real-time data via Doris-Spark-Connector. We put almost all our real-time data in Apache Doris, and part of our offline data in Airflow for DAG batch tasks. Our real-time data is in huge volume so we really need a solution that ensures high query efficiency. Meanwhile, we have a 20-member team for data operation and we need to provide data dashboarding services for all of them. That can be challenging for real-time data writing and demanding in query concurrency. Luckily, Apache Doris makes all this happen. User-Defined Conversational Data Analysis This is my favorite part because we have proudly leveraged our natural language processing (NLP) capability in data queries. A normal BI scenario works this way: Data analysts customize the dashboards on a BI platform based on the needs of data users (e.g. financial department and product managers). But we wanted more. We wanted to serve more unique needs of data users, such as roll-up and drill-down at any designated dimension. That's why we enable user-defined conversational data analysis. Unlike normal BI cases, it is the data users but not data analysts who are talking to BI tools. They only need to describe their requirements in natural language and we, utilizing our NLP capabilities, will turn them into SQL. Sounds familiar? Yep, . Except that we've been optimizing it for a long time and fine-tuned it for better integration with Apache Doris so our data users can expect higher hit rates and more accurate parsing results. Then, the generated SQL will be sent to Apache Doris for execution. In this way, data users can view any breakdown details and roll up or drill down any fields. this is like a domain-specific GPT-4 How Apache Doris makes this work well? Apache Doris has the following strengths compared to pre-computed OLAP engines such as Apache Kylin and Apache Druid: Flexible query models that support user-defined scenarios Support for table association, aggregate computing, and breakdown queries Quick response time Our internal users have been giving positive feedback regarding this conversational data analysis. Suggestions We accumulate some practical experience regarding the usage of Apache Doris that we believe can save you some detours. Table Design Use Duplicate table for small data volumes (e.g. less than 10 million rows). Duplicate tables support both aggregate queries and breakdown queries so you don't need to produce an extra table with all the detailed data. Use Aggregate table for large data volumes. Then you can do roll-up indexing, speed up queries via materialized view, and optimize aggregation fields on top of the Aggregate tables. A downside is that since Aggregate tables are pre-computed tables, you will need an extra breakdown table for detail queries. When handling huge amounts of data with many associated tables, generate a flat table via ETL, and then ingest it to Apache Doris, where you can do further optimizations based on the Aggregate table type. Or you can follow the recommended by the Doris community. Join optimizations Storage We isolate hot and warm data in storage. Data of the past year is stored in SSD, and data older than that is stored in HDD. Apache Doris allows us to set a cool-off period for partitions, but the relevant configuration can only be made upon partition creation. Our current solution is automatic synchronization, in which we migrate a certain portion of the historical data from SSD to HDD to make sure that the data of the past year is all placed on SSD. Upgrade Make sure to back up the metadata before upgrading. An alternative method is to start a new cluster, back up the data files to a remote storage system such as S3 or HDFS via Broker, and then import data from the old cluster data into the new cluster by way of backup recovery. Performance After Version Upgrade Starting with Apache Doris 0.12, we've been catching up with the releases of Apache Doris. In our usage scenarios, the latest version can deliver several times higher performance than the early ones, especially in queries with complex functions and statements involving multiple fields. We really appreciate the efforts by the community and strongly advise you to upgrade to the latest version. Apache Doris Summary To wrap up what we've gained from Apache Doris: Apache Doris can be a real-time + offline data warehouse so we only need one ETL script. It saves us a lot of development work and storage costs and also avoids inconsistency between real-time and offline metrics. Apache Doris 1.1.x supports vectorization and thus can deliver 2~3 times higher performance than older versions. Test results show that Apache Doris 1.1.x is on par with ClickHouse in flat table query performance. Apache Doris is powerful itself with no dependency on other components. Unlike Apache Kylin, Apache Druid, and ClickHouse, Apache Doris requires no other component to fill any technical gap. It supports aggregation, breakdown queries, and associated queries. We have migrated over 90% of our analysis to Apache Doris and that has made our O&M much lighter and easier. Apache Doris is easy to use as it supports MySQL protocol and standard SQL.

The Importance of Performant Data Processing Architecture in Creating AI Chatbots

In the early stages of Web3 deployment, most projects focused on entertainment, gaming, and social networking. However, as Web3 technology evolves and matures, it will support deeper verticals such as manufacturing, engineering, and smart cities. In addition to the technical requirements to reach this stage, it also requires a storage infrastructure that is more closely aligned with social acceptance, privacy and security, and content creation needs. The success or failure of a storage project will depend on its ability to capture and store data from the surrounding environment. The next requirement after “get the data” will be “interact and save the data,” which means that not only does the data need to be represented in a meaningful way, but it must also be high-performance and responsive. Source: Messari Privacy and security issues are also critical because Web3 involves virtual assets that can contain large amounts of multiple types of data, potentially exposing users to more dangerous data environments. We think MEMO’s security and privacy technologies will play an important role in redefining the underlying infrastructure of Web3. People always want more Not only is data storage for Web3.0 important, but we also need to think about how to process all that data and make it operable to users. Seamless sharing is a higher-level vision. Security and stability are eternal value pursuits. Security problems are mainly caused by storage service providers. If the economic model of the project side is not centered on the interests of users, it will inevitably be accompanied by many security risks. Stability issues also arise because centralized service providers can always go down at any time. Decentralized shared storage is in the core interests of users As a Web 3.0 infrastructure based on edge storage devices, MEMO is supported by the MEMO file system. By organizing and leveraging globally available data storage resources, MEMO aims to build a decentralized data storage layer with high security and high availability. As a Web3.0 solution, MEMO provides low-cost storage services and utilizes the shared economy model and high compatibility of decentralized distributed storage to build a sustainable economic model for decentralized storage. Source: MEMO Centralized services are not really necessary for users. On an infrastructure level, MEMO ensures high availability by providing unblocked network access and storage that no one can delete. In such an environment, Web3 users can generate and access data in the real world or virtual world from anywhere, across multiple devices. Storage has evolved completely out of the cycle. For sure, once Web3 is developed and applied, it will generate a lot of data, which will put a lot of pressure on the real world to handle data. Therefore, data storage will be an inevitable challenge to implement exponential applications. Distributed storage provides positive incentives At present, the most suitable data storage tool for Web3 storage is undoubtedly distributed storage. In contrast to the centralized management of traditional application platforms, the MEMO network is deployed on a blockchain and uses distributed storage to process data. Memo’s MEFS file storage system provides a highly scalable and low-cost distributed storage approach for the ZB-class data storage market. MEFS ensures high scalability and sustainability of systems at a low marginal cost by integrating available resources. This mode effectively makes use of idle storage resources and meets the hard requirements of Web3 for mass data storage. Source: MEMO As a decentralized storage system, it is very important to establish a perfect incentive mechanism to reward storage providers, punish fraudulent entities, and effectively coordinate the division of labor among storage users, storage resource providers, and metadata managers. MEMO creates three roles (user, guardian, provider) for a decentralized community within a completely autonomous system. These roles interact with each other through smart contracts. With a worldwide network of storage nodes, MEMO now has 100 petabytes of storage on the entire network. MEMO is designed as a global edge storage device with a low node threshold, even on a home computer. In addition, Memo only provides storage space for actual needs, rather than competing for massive computing power to produce blocks. Mappings of role interactions are stored on relevant devices with valid data to avoid wasting resources on the meaningless competition for computing power. The beautiful double helix of Web3 storage As with any technology, storage projects should be cautious and consider the possible consequences of such technologies. In the Web3 era, privacy and security are always unavoidable topics. Web3 closely links real life with the virtual world and leads to the potential influence of the virtual world on real-life data. For example, hackers can exploit technical and administrative flaws to steal personal data and track and mine unauthorized access to private content. Security resilience of fragmented data Compared with traditional cloud storage service providers, distributed storage provides many security advantages. The Memo is fragmented and networked, encrypted, and stored on nodes. This makes it impossible for the workstation hosting the user’s files to view them, leading to greater privacy. MEFS uses proof of reliability and proof of time to improve system reliability. It also uses random beacons and BFT protocols to verify proof and avoid malicious manipulation and single points of failure. Because the consensus mechanism operates off the chain, a degree of flexibility is preserved. This method not only ensures data security and reliability but also allows users to freely choose the storage period to meet different requirements. Once, for some reason, network nodes are maliciously attacked or fail, some data fragments are exposed or lost without any serious consequences to users. Because the data is encrypted, and only a small part of the data file. At the same time, Memo’s diverse and optional fault-tolerant mechanisms provide the Memo storage protocol with high reliability. Source: MEMO RAFI technology can be used to guarantee data recovery in case of uncontrollable natural disasters or loss of nodes or destruction of data fragments caused by human causes, which basically ensures that user data will never be lost during the storage period. And the whole system is fault-tolerant, a single node being destroyed will not make the whole system crash, through redundant storage files, so that the lost data can be easily recovered. The privacy issues that come with sharing Web3 is about privacy and data sovereignty. In the process of data storage state verification, Memo uses more advanced privacy computing technologies such as zero-knowledge proof, homomorphic encryption, secure multi-party computing, etc. This approach maximizes user privacy as supported by any third-party authentication. The Memo is encrypted using asymmetric encryption. Only the user with the private key can decrypt the data. In MEMO distributed storage protocol, data is encrypted at the source client and transmitted to the network in the ciphertext. The provider node that stores the data receives the data in ciphertext, which ensures that the data is encrypted during both dynamic transmission and static storage. Memo implements absolute user privacy. Files stored in the MEFS system are encrypted at the source client, segmented using a combination of multiple copies and erased redundant code, and finally stored at nodes across the network. This encrypted data can only be accessed and modified by the user, not by the MEMO project or anyone else. Source: MEMO Of course, encryption and privacy are only necessary defaults. MEMO enforces a more thorough privacy strategy. MEMO also allows for a variety of scenarios where different data will be used in the future. MEMO designs editable privacy policies based on different privacy requirements. The privacy policy encrypts at the source, allowing for more thorough enforcement of data privacy protection. At the same time, the privacy policy can also be edited to meet the needs of different scenarios. These scenarios will become the foundation for decentralized identity governance in the future Web3 era. Bottom line: Stand out in crowded storage space Although Web3 is not fully matured and requires blockchain to embrace Web2 faster, we fully believe that the formation of Web3 will be a complete Internet storage paradigm reform and data ownership innovation. In terms of protecting data privacy, this step usually needs to be supported by privacy computing technology. If MEMO can experiment more in the realm of decentralized computing, then as a powerful overall data solution it can support more complex DApps that can perform more complex calculations at a much lower cost than performing smart contracts on the blockchain. Computing doesn’t seem as crowded as storage at the moment. Source: MEMO As a result, powerful competitors are eyeing up storage. Of course, we can’t ignore that projects like Arweave already have a well-established ecosystem. We have seen the excellent L2 protocol Metis choose MEMO as a storage partner for its high security, reliability, and availability. Transformational collaboration in the traditional Web2 business, extensive deployment of other protocols, and the development of more native DApps will drive the growth of MEMO to a greater depth. By Kyle, Investment Manager@Bing Ventures

The Beautiful Double Helix of High Responsiveness and Decentralized Storage in the Web3.0 Era

Modern organizations need complex functioning properly to provide goods and services at the expected level of performance. Therefore, losing critical parts or the whole infrastructure can put the organization on the edge of disappearance. Disasters remain a threat to production processes. IT infrastructures What is a disaster? A disaster is challenging trouble that instantly overwhelms the capacity of available human, IT, financial and other resources and results in significant losses of valuable assets (for example, documents, intellectual property objects, data, or hardware). In most cases, a disaster is a sudden chain of events causing non-typical threats that are difficult or impossible to stop once the disaster starts. Depending on the type of disaster, an organization needs to react in specific ways. There are three main types of disasters: Natural disasters Technological and human-made disasters Hybrid disasters A natural disaster is the first thing that probably comes to your mind when you hear the word “disaster”. Different types of natural disasters include floods, earthquakes, forest fires, abnormal heat, intense snowfalls, heavy rains, hurricanes and tornadoes, and sea and ocean storms. Technological disaster is the consequence of anything connected with the malfunctions of tech infrastructure, human error or evil will. The list can include any issue from a software disruption in an organization to a power plant problem causing difficulties in the whole city, region or even country. These are disasters such as global software disruption, critical hardware malfunction, power outage, and any electricity supply problem, malware infiltration (including ransomware attacks), telecommunication issues (including network isolation), military conflicts, terrorism incidents, dam failures, chemical incidents. The third category to mention describes mixed disasters that unite the features of natural and technological factors. For example, a dam failure can cause a flood resulting in a power outage and communication issues across the entire region or country. What is disaster recovery? Disaster recovery (DR) is a set of actions (methodology) that an organization should take to recover and restore operations after a global disruptive event. Major disaster recovery activities focus on regaining access to data, hardware, software, network devices, connectivity, and power supply. DR actions can also cover rebuilding logistics, relocating staff members, and purchasing office equipment, in case of damaged or destroyed assets. To create a disaster recovery plan, you need to think over the action sequences to complete during these periods: Before the disaster (building, maintaining, and testing the DR system and policies). During the disaster (applying the immediate response measures to avoid or mitigate asset losses). After the disaster (applying the DR system to restore operation, contacting clients, partners, and officials, and analyzing losses and recovery efficiency). Here are the points to include in your disaster recovery plan Business impact analysis and risk assessment data At this step, you study threats and vulnerabilities typical and most dangerous for your organization. With that knowledge, you can also calculate the probability of a particular disaster occurring, measure potential impacts on your production and implement suitable disaster recovery solutions easier. Recovery objectives: defined RPO and RTO RPO is the recovery point objective: the parameter defines the amount of data you can lose without a significant impact on production. RTO is the recovery time objective: the longest downtime your organization can tolerate and, thus, the maximum time you can have to complete recovery workflows. Distribution of responsibilities A team that is aware of every member’s duties in case of disaster is a must-have component of an efficient DR plan. Assemble a special DR team, assign specific roles to every employee and train them to fulfill their roles before an actual disaster strikes. This is the way to avoid confusion and missing links when real action is required to save an organization’s assets and production. DR site creation A disaster of any scale or nature can critically damage your main server and production office, making resuming operations there impossible or extraordinarily time-consuming. In this situation, a prepared DR site with replicas of critical workloads is the best choice to minimize RTO and continue providing services to the organization’s clients during and after in an emergency. Failback preparations Failback, which is the process of returning the workloads back to the main site when the main data center is operational again, can be overlooked when planning disaster recovery. Nevertheless, establishing failback sequences beforehand helps to make the entire process smoother and avoid minor data losses that might happen otherwise. Additionally, keep in mind that a DR site is usually not designed to support your infrastructure’s functioning for a prolonged period. Remote storage for crucial documents and assets Even small organizations produce and process a lot of crucial data nowadays. Losing hard copies or digital documents can make their recovery time-consuming, expensive or even impossible. Thus, preparing remote storage (for example, VPS cloud storage for digital docs and protected physical storage for hard copy assets) is a solid choice to ensure the accessibility of important data in case of disaster. Equipment requirements noted This DR plan element requires auditing the nodes that enable the functioning of your organization’s IT infrastructure. This includes computers, physical servers, network routers, hard drives, cloud-based server hosting equipment, etc. That knowledge enables you to view the elements required to restore the original state of the IT environment after a disaster. What’s more, you can see the list of equipment required to support at least mission-critical workloads and ensure production continuity when the main resource is unavailable. Communication channels defined Ensure enabling a stable and reliable internal communication system for your staff members, management, and DR team. Set the order of communication channels’ usage to deal with the unavailability of the main server and internal network right after a disaster. Response procedures outlined In a DR plan, the first hours are critical. Create step-by-step instructions on how to execute DR activities, monitor and conduct processes, failover sequences, system recovery verification, etc. In case a disaster still hits the production center despite all the prevention measures applied, a concentrated and rapid response to a particular event can help mitigate the damage. Incident reporting to stakeholders After a disaster strikes and disrupts your production, not only DR team members should be informed. You also need to notify key stakeholders, including your marketing team, third-party suppliers, partners, and clients. As a part of your disaster recovery plan, create outlines and scripts showing your staff how to inform every critical group regarding its concerns. Additionally, a basic press release created beforehand can help you not to waste time during an actual incident. DR plan testing and adjustment Successful organizations change and expand with time, and their DR plans should be adjusted according to the relevant needs and recovery objectives. Test your plan right after you finish it and perform additional testing every time you introduce changes. Thus, you can measure the efficiency of a disaster recovery plan and ensure the recoverability of your assets. Optimal DR strategy applied The DR strategy can be implemented on a DIY (do it yourself) basis or delegated to a third-party vendor. The former choice is the way to sacrifice reliability in favor of the economy, while the latter one can be more expensive but more efficient. The choice of a DR strategy fully depends on your organization’s features, including the team size, IT infrastructure complexity, budget, risk factors, and desired reliability, among others. Summary A disaster is a sudden destructive event that can render an organization inoperable. Natural, human-made, and hybrid disasters have different levels of predictability but they are barely preventable at an organization’s level. The only way to ensure the safety of an organization is to create a reliable disaster recovery plan based on the organization’s specific needs. The key elements of a DR plan are: Risk assessment and impact analysis Defined RPO and RTO DR team responsibilities distributed DR site creation Preparations for failback Remote storage Equipment list Established communication channels Immediate response sequences Incident reporting instructions Disaster recovery testing and adjustment Optimal DR strategy choice Also published here.

A Guide on Disaster Recovery for IT Systems

When you enter the NFT market as a newcomer, you will most likely encounter many NFT projects that sound almost too good to be true. It does not matter whether you have no experience or tos of experience, people still tend to ignore these easy-to-remember red flags to separate promising NFT projects from the shady ones. To ensure that you don’t make these massive mistakes by getting into a suspicious NFT project, we gathered the TOP 6 red flags to not avoid by any means. https://www.youtube.com/watch?v=t99EJu_7GAQ 1.Undoxxed team If you look at the project’s website and it does not have links to real Instagram, Twitter, or LinkedIn accounts, do not buy the NFT to prevent the possibility of getting scammed. A doxed team, regardless of skill set or background, adds a layer of trust that there are real people building real projects. Recommendation: Question their discord as to why there is no personal information included. If they cannot provide an answer as to why that satisfies your standards, stay away. 2. Fake Twitter or Discord followers/accounts There are plenty of sources that will chat on behalf of the team on their Discord server. For example, Fiverr provides a message every min per hour just for $20. Different websites such as GetViral sell Twitter followers for almost no money will create an illusion of a reliable following. Recommendation: Do a quick audit, for instance, use . Look through engagement on posts to see if there are any real people or just bots. If the account has 120k followers and only 50 likes, it is a red flag. Also, check if any notable people follow the account. TwitterAudit 3. Artificial hype Most shady NFT projects often purchase celebrity endorsements to generate unrealistic publicity around the project. Big names in the field of entertainment such as Thiago Silva can be hired for a silly amount of money to gain people’s attention in the sketchy project. Recommendation: It is highly recommended to do some research. Dig into whether the partnerships are officially approved or just paid “partnerships”. 4.Unrealistic mint price Hype-based pricing is certainly a real problem in the NFT space. The golden rule to identify a suspicious NFT project is to analyse the mint price. Behind a high mint price there is almost always the combination of hype and FOMO which drives the price unrealistically high. Many projects have nothing of substance to back their price and rely solely on “influencers” to boost the price. This results in investing money into those projects because of FOMO and losing everything when the hype dies. Real community builders start the mint price at a reasonable level and do not extract all the liquidity out of the market. Just because the NFT project can demand a high price does not mean they should. Recommendation: A project that allows the original minters to participate in an affordable way is what builds loyal supporters of the project to stick through the storm and lulls. As an opposite, projects that mint at ridiculously high prices often have difficulty finding support during tough times. Therefore, it is important to invest in projects you truly believe in. 5.Predatory tactics Floor sweeps: Sweeping the floor in the NFT world means when a specific project buys all its minted NFTS at the floor price. The floor price is the minimum “ask” or the lowest price an NFT can be sold on the secondary market. It is the most popular metric for tracking a project’s performance over time and its relative success compared to others. As an emerging project, floor sweeping can be a method to attract newcomers by guaranteeing low entry points. Banning members: Another predatory tactic to look out for is banning members from listing below prices. This means a member of the project is being kicked out of the community for selling their NFT at a much lower price than the fishy owners of the projects approved. Echo chamber: A big red flag is the existence of an echo chamber. It is an environment where a person only encounters information or opinions that reflect and reinforce their own. This may limit the information the users consume and promote ideas relevant to the NFT project. Recommendation: Step out of the chamber (Discord, forums etc) for a few days. This often allows for the head to clear so better judgement can be made. Other popular red flags to watch out for are harassment of any kind, threats, and piggybacking of popular projects. 6.Meta cliché If the project fails to bring more than little innovation by introducing repetitive meta or roadmaps, be cautious. This can be an alarming indicator that the project is most likely going to take advantage of your money to cover its own interests. In addition, if the project fails to address legality concerns over securities and insurance of tokens, consider exiting the project. Meta is easy to copy, and tokens can be launched only in a matter or hours. On the contrary, real economies take months or years to create. The lack of ability to create proper Tokenomics or P2E for sustainability and longevity is also a worrying measure. For instance, the owners of the Bored Ape Yacht Club can participate in exclusive clubs and areas of the BAYC. This is a good way of thinking in the future and gaining people’s trust. Tokenomics: The goal of a Tokenomic analysis is to understand the potential value of the project by considering all aspects of a token’s creation and management, including its supply, allocation, and distribution. The reason why Tokenomics is so important is that it helps to ascertain the future worth of an asset by giving an insight into the profitability of one asset over the other in the future. P2E (Play to Earn): indicates a type of gaming that hinges on NFT technologies. For example, gamers can play video games and virtual worlds for rewards by making an initial investment in the NFT. Identifying these red flags may be a long arduous journey of separating the real NFT projects from the quick cash-grabs, but once you understand the importance of it, success is guaranteed. Unfortunately, there are no blueprints to follow in this new industry, which means there are no right or wrong ways to approach a project. Start by looking for niches and teams with the ability to execute. Find out who is the founding team, and how they work, what their values and grand vision are. If they show lack in respect, transparency, or communication, consider moving on. ‍ Thank you for reading 💗 We hope this article helps you avoid trouble in the NFT world, for more educational articles check out our blog at https://coinboosts.io/blog This article is published by team of ex-investors & market researchers on Crypto & NFT field now offering marketing help to projects in the same field. CoinBoosts

How to Avoid NFT Scams and Rug Pulls: 6 Red Flags to Avoid in 2022

Today, a new paradigm is emerging in the online gaming industry—one that allows gamers to not only earn money within games but also own a part of the games they play. Instead of buying or downloading a game in a “pay to play” format with in-game micro-transactions, players can now use digital currencies and NFTs to purchase in-game digital products to both “ ” and “ .” play to earn play to build This new breed of gaming experience, in which the players can earn a portion of the game’s in-game currency by simply playing the game, is known as a “play-to-earn” NFT game. The concept of play-to-earn is straightforward. The more you play, the more digital currencies or NFTs you can earn. These games offer users NFTs for the time and effort they put in. They’re also a great way to earn crypto while having fun and getting to know your favorite game better. estimates that the full value of the gaming industry now exceeds $300 billion. Accenture This is “more than the combined markets for movies and music, driven by a surge in mobile gaming and an emphasis on social interaction during the COVID-19 pandemic.” With many play-to-earn games already online, they will only contribute to the explosive growth of the gaming industry. How NFTs Contribute to the Online Gaming Economy Play-to-earn games are another way game designers are creating and leveraging in-game NFT items and rewards that can be bought and sold within the game or via third-party marketplaces such as . Opensea For instance, let’s say you’re designing a game that involves racing. In the game, players earn digital currencies if they win a race. Because the racetrack is built on a blockchain, the in-game currencies or coins can’t be copied or cloned. They’re also transferable, which means you can trade them for other coins, or sell them to other players in the game for fiat currencies. Some of the most successful play-to-earn games such as let players purchase, battle and breed virtual characters that are minted on the blockchain and then sell them on third-party marketplaces. Axie Infinity Ethereum Combining Play to Earn with Play to Build Games Just like the real world economy, gamers can choose what they want to specialize in or play within the metaverse. Play to Build game mechanics create sustainable economies within metaverse worlds where players can play to earn NFTs or connect on/off-chain activities to build NFTs. In the case of , Play to Build links the real-world behaviors on the Phala network blockchain with the activities of Phala World in the Metaverse. Phala World is a Metaverse based on the blockchain that utilizes the ‘Play to Build’ gaming concept. The upcoming game combines user behavior, characters, communities, and sci-fi stories on the Phala blockchain, while integrating strategy, development, MMORPG, and other game types. Phala World Phala Network Phala World is also a community-driven game that rewards community contributions and participation to Phala network in-game assets. Players can earn, trade, and build while playing the game. Phala is also collaborating with and to develop NFT and Metaverse gaming infrastructure. RMRK Bit.Country Phala’s vision is to build the world’s first ‘Play- to- Build’ Metaverse game that connects Phala World and on/off-chain actions in the real world, where millions of players can turn their passion for gaming into real assets. Players will be able to play a game they enjoy, while simultaneously earning, trading, and building in a massive, open-world economy. Phala World will combine the following gameplay attributes: A player's in-game identity is called a “Spirit NFT” and represents a non-transferable NFT that combines attributes and activity from Twitter, Discord and other data on the Phala chain. For example, if a player commits code to Phala's GitHub, the in-game NFT avatar value will increase. Phala will use the decentralized DID protocol to implement this system developed with . NFTs as game identity: Litentry The back-end system of the game records the player's in-game experience acquisition, construction records, etc., so as to push the data to the Spirit NFT for permanent records. We plan to deploy this game service using Fat Contract running on Phala's decentralized computing nodes. Unlike traditional smart contracts, Fat Contracts provide low-latency, computationally-intensive services, and can even interact with HTTP requests in the contract. : mapped community roles with game roles (career), and mapped on-chain activities with game activities. For example, A Bot-druid is actually a miner on the Phala blockchain, and the Druid can summon Robot fighters which match his computation nodes amount on the Phala blockchain. Mapping : NFT avatars are divided into different camps according to the user's role on-chain or off-chain. In Phala World, different camps can compete according to the construction speed. The winner can unlock a metaverse land plot based on auctions. Socialization

A New Paradigm: From "Play to Earn" to "Play to Build" Gaming

What is the ideal "quantum of information" or "minimal unit of meaning" and why ask such a question? There is a lot of pain associated with this, often not even realized. We offer a solution, but first, you need to figure out what it is for. We recommend you to read in a series. the first article Retrospective Relational tables, document-oriented databases, jsonb stores ... We often use the model in the table/collection as the minimum unit of meaning. The model consists of columns/fields with a different structure and reflects some real object or abstract concept defined by the author. This approach creates problems: Lots of address spaces. (If you do not see it as a problem, then soon there will be an article exclusively on this topic, and you will see why this problem is real). Many control points of the data structure are expensive to change. Compatibility only at the level defined by the author. Failure to fully describe something new without creating another table/collection. The inability to separate objects from the relationships between them. All of these problems are addressed in the Deep.Case associative model of data. Let's dig into it Deep.Case operates with the Link concept as a minimal unit of meaning/quantum of information. Links table Links (a network of links) are very similar to a graph, however, the graph has a division into nodes and edges referring only to nodes. Links do not divide these address spaces. This allows links to refer to links and carry any meaning that the author of the data models can put in them. Link structure The link structure consists of the required unique and used as the type of this link. The optional and fields can only be specified together. id type_id from_id to_id Types for creating links are easily created by the user himself within the project model or supplied with imported model packages. The specified and fields refer to other links. Any relationship can be described with such links. from_id to_id {
  links(where: { id: { _eq: 8 } }) {
    id
    type_id
    from_id
    to_id
  }
} {
  "data": {
    "links": [
      {
        "id": 8,
        "type_id": 1,
        "from_id": 7,
        "to_id": 6
      }
    ]
  }
} Link as a node You can leave and fields empty in links. Such links play the role of a node, a point, an object of relations. from_id to_id {
  links(where: { id: { _eq: 28 } }) {
    id
    type_id
    from_id
    to_id
  }
} {
  "data": {
    "links": [
      {
        "id": 28,
        "type_id": 6,
        "from_id": 0,
        "to_id": 0
      }
    ]
  }
} Link as a link If and are specified, the link plays the role of a relationship between nodes or links. It can answer the question of how they are related using . The environment of a node with links can answer many questions about its meaning, relationships, purpose, value, and state. from_id to_id type_id {
	links(where: { id: { _in: [6,7,8] } }) {
    id
    type_id
    from_id
    to_id
  }
} {
  "data": {
    "links": [
      {
        "id": 6,
        "type_id": 1,
        "from_id": 0,
        "to_id": 0
      },
      {
        "id": 7,
        "type_id": 1,
        "from_id": 0,
        "to_id": 0
      },
      {
        "id": 8,
        "type_id": 1,
        "from_id": 7,
        "to_id": 6
      }
    ]
  }
} Unified GraphQL API This API allows to do a lot of things, such as traversal to all children/parents in certain subtrees using index. But there will be separate articles about this. Obviously, the structure of the link itself is available there, and also from a link, you can go to other links both by its links ( and ) and by backward references from other links (outgoing and incoming). For example, you can go to all links that refer to this link by (these links go from it) using relationship , or by (These links go to it) using relationship . from_id to_id from_id out to_id in {
	links(where: { id: { _eq: 8 } }) {
    id
    type { id }
    from {
		id
	    type_id
	    from_id
	    to_id
		out {
			id
		    type_id
		    from_id
		    to_id
		}
	}
	to {
		id
	    type_id
	    from_id
	    to_id
		in {
			id
		    type_id
		    from_id
		    to_id
		}
	}
  }
} {
  "data": {
    "links": [
      {
        "id": 8,
        "type": {
          "id": 1
        },
        "from": {
          "id": 7,
          "type_id": 1,
          "from_id": 0,
          "to_id": 0,
          "out": [
            {
              "id": 8,
              "type_id": 1,
              "from_id": 7,
              "to_id": 6
            }
          ]
        },
        "to": {
          "id": 6,
          "type_id": 1,
          "from_id": 0,
          "to_id": 0,
          "in": [
            {
              "id": 8,
              "type_id": 1,
              "from_id": 7,
              "to_id": 6
            },
            {
              "id": 13,
              "type_id": 1,
              "from_id": 6,
              "to_id": 6
            },
            {
              "id": 24,
              "type_id": 22,
              "from_id": 23,
              "to_id": 6
            }
          ]
        }
      }
    ]
  }
} SQL-like queries We can receive not only the data on the structures described above. We can use the SQL-like predicate to perform a variety of complex filtering at each level. where {
  links(where: {id: { _eq: 6 } }) {
    id
    type { id }
    from { id }
    to { id }
    out(where: { from_id: { _eq: 6} }) {
      id
      type_id
      from_id
      to_id
    }
    in(where: { type_id: { _eq: 1} }, limit: 1) {
      id
      type_id
      from_id
      to_id
    }
  }
} {
  "data": {
    "links": [
      {
        "id": 6,
        "type": {
          "id": 1
        },
        "from": null,
        "to": null,
        "out": [
          {
            "id": 13,
            "type_id": 1,
            "from_id": 6,
            "to_id": 6
          }
        ],
        "in": [
          {
            "id": 8,
            "type_id": 1,
            "from_id": 7,
            "to_id": 6
          }
        ]
      }
    ]
  }
} Subscriptions And all of this already with support for subscriptions. You can simply describe to which structure you want to subscribe - and you will receive updates on the results of your query in real-time. subscription {
  links(where: { from_id: { _eq: 7 }, to_id: { _eq: 6 } }) {
    id
    type_id
  }
} Support associative technologies We create a development environment (boxed CE / EE version and SaaS version), which allows you to use data storage for solving your business problems with the ability to adapt to any business changes using an associative approach. We will create a distributed network of server clusters in a single associative space, there also will be no need to think about regional legislation while you are creating a project. We create a culture of publishing reusable data models with their behavior. Join our community on . Sign up for early access on our Waitlist or support us on . Discord Patreon you can find links to drafts of future articles in development, links to code sources, plans for project and product management, and invest presentations. On our site

Associative Links Explained

Many people, including myself, are purchasing and collecting LANDs on The Sandbox, and you’re probably asking yourself “why though?!” - The answer to that question is because they know owning LAND on The Sandbox will make them rich. What is The Sandbox? is a decentralised community-driven gaming, digital art and game development ecosystem where creators and designers can create and monetise their art NFTs, art experience and gaming experiences on the Ethereum blockchain. The Sandbox What is LAND on The Sandbox? LAND is a non-fungible ERC-721 token on the Ethereum blockchain. This NFT is a piece of digital real-estate that can be monetised in a variety of ways, which this article will explain in better detail below. LANDs are also a key that will enable you to be involved in the governance of The Sandbox metaverse. LANDs are a finite resource, with only 166,464 of them in existence. How is owning LAND on The Sandbox going to make me rich? Owning a piece of digital real estate called LANDs on The Sandbox will open the door to many opportunities for you to earn yourself a very tidy trickle of income. Let’s list all the ways that LAND could make you a very rich human indeed. Hosting Experiences The main purpose of LANDs on The Sandbox is to allow people to host experiences on them, such as games, art galleries, shops, dioramas, interactive education, and so on. These experiences can be designed and built via The Sandbox’s own game development software, called the Game Maker, and then published onto any LANDs that the creator owns. Players can be charged an entry fee in cryptocurrency in order to access the experience that is published on the LAND. Staking An upcoming feature in The Sandbox will allow LAND owners to stake cryptocurrency on their LANDs to earn passive rewards in return. One of these rewards are GEMs, an ERC-20 token which is highly coveted and sought-after by asset designers. Alongside the regular staking rewards, these GEMs can be sold on the marketplace as well. If you are providing , the number of LANDs you own also act as a multiplier, increasing the amount of the SAND cryptocurrency that you earn from liquidity mining. SAND-ETH liquidity to the UniSwap liquidity pool Renting LAND owners will also be able to rent their LANDs out to others, including game designers and development studios who missed their chance to grab a LAND in the initial sales. Once all of the LANDs have been sold, the demand for LANDs to rent will soar as more and more people discover The Sandbox and decide they want to publish an experience there. Host Contests & Giveaways Contests and giveaways can be hosted on LANDs, attracting a healthy number of paying customers to visit your LAND in order to enter this contest or giveaway. Alternatively, you could allow other people to host contests or giveaways on your LANDs in order to promote themselves - for a fee of course. Selling Ad Space Thanks to billboard-like features that will allow you to embed links, images, NFT previews and video files, you can sell prime advertising space on your LAND. Depending on the exact location of your LAND, some businesses, such as indie game development studios, will be interested in advertising their business on your LAND, which you could contractually charge them for. Self-Promotion Ads & Affiliate Linking Are you an affiliate? Are you a business owner? An author? An artist? Or anyone that has a product or service to sell? Then why not expand your reach by using some of your ad space on your own LAND to advertise yourself to players and visitors who would normally probably not realise your product or service existed. Selling asset NFTs Should you decide to publish an experience on your LAND, you will also be able to set certain entry requirements, besides paying a fee to access the experience. One of the entry requirements that you can set is to require players to own a particular asset NFT first. For example, in order to play a swashbuckling pirate game you have published onto the LAND, a player might be required to buy a weapon from an NFT sword collection that you also published onto the marketplace. Selling LANDs And, of course, another way that you could get rich from LANDs is from selling them, especially if they are in high-traffic and highly-coveted areas of the metaverse. Though, admittedly, if you patiently hold onto your LANDs for longer you will, in the long run, likely make more money from a combination of the other methods explained above. Become a LAND owner today and get rich! So there you have it, some of the ways that you could become rich from owning LAND on The Sandbox. There will be more monetisation opportunities with LAND in the future, so I suggest that you join The Sandbox community and keep an eye on the development news. However, because LAND is a finite resource, you should not delay in acquiring yourself a piece of this fantastically easy money-making digital real estate! Helpful links: . The Sandbox’s official knowledge base for information and guides . The Sandbox’s official website and marketplace . The Sandbox’s official Medium blog . The Sandbox’s official Discord server I’ll see you later! Whether that will be waving to you as you sail past me in your million-dollar yacht, or as a minimum wage waiter/waitress/waitperson serving LAND owners expensive champagne, will be entirely up to you. DISCLAIMER: This article was written by a member of The Sandbox community who owns LANDs. Thus, the writer has a vested interest in the company and its products. The opinions in this article belong to the author alone and should not be taken as professional investment advice. Please make sure you take the time to do your own research, to ensure that investing in LAND is right for you. This article is part of The hosted by HackerNoon in partnership with Gaming Metaverse Writing Contest . The Sandbox Submit your #gaming-metaverse story today for your chance to win up to $2000 in SAND tokens.

Why Owning LAND on The Sandbox Could Make You Rich

A link behavior flow diagram from the early days of . Branch we published Part 2 of this story, in April, 2019. It discusses the future of cross-platform measurement and UX. UPDATE: The Death of App Attribution This is the story of Branch . Not the chronological history, but the reason behind why we exist. If you have ever wondered how “ deep linking ” came to be both a buzzword and an industry dirty word at the same time, here is the answer. It’s also the solution to the impending crisis of content discovery on the internet. Links are awesome. They’re the foundation of the web as we know it, and since this is the 21st century, we’ve all been surrounded by links for most of our lives. Pretty much everyone intuitively understands how to one, but do you ever stop to think about how a link actually Probably not, because the concept is so darn simple: when you click on a link, you are transported somewhere you wanted to go. use functions? With such an obvious process, you could be forgiven for missing just how fragile this system really is. Links on the Web vs. Links on Mobile Native code has many advantages over web experiences, but content accessibility and discoverability are certainly not among them. See, in the early days of the web, when each browser implemented things differently and “the internet” was something most people experienced as “that place outside of AOL,” there was a real risk that links could have ended up not “just working.” It was the widespread adoption of open standards that gave us the web as we know it today, and made search engines like Google (essentially just massive, ranked databases of trillions of links) possible. However, even this wasn’t without controversy. We now take it for granted that Google search results consist of links that point directly to content, but many early webmasters were at the thought of users being “deep linked” into the middle of their sites. The proposed alternative was for every website to be a walled garden, accessible only through its own homepage and with internal content unreachable by any other approach. Fortunately for us, this future never materialized. The web has remained open and deep linking (whether via search engine or otherwise) is something we now use every day. less than thrilled But does this alternative version of the early web sound somewhat familiar? It should, because . Native code has many advantages over web experiences, but content accessibility and discoverability are certainly not among them. So, now we have come full-circle back to the early days of the web, except that this time the walled gardens are a very real technical limitation rather than just a theoretical possibility. this is the current reality for mobile apps Solving the Walled Garden Problem on Mobile by Rethinking Links Can content be accessible and discoverable, regardless of platform or device type? The web and its well-defined link standards are not going away anytime soon, but the equivalent mechanisms for iOS and Android apps are still remarkably immature, despite anything Apple and Google may claim to the contrary. Right now, the behavior of a link often differs depending on things as innocuous as the version of the app in which it was viewed prior to being clicked. To make matters worse, the digital landscape is now changing so rapidly that it is no longer safe to assume anything about how a given user will reach you — yesterday it was your desktop website, today it is your mobile website, tomorrow it could be in your native app, but next week it may be a completely new channel that hasn’t even been invented yet. The recent trend in multi-platform linking (including iOS Universal Links, Android App Links, and Facebook App Links) has been distorting web links to accommodate apps. With this approach, a regular web link points to multiple destinations simultaneously and the local client is responsible for determining which one to load. It’s fundamentally confusing, a hack on the existing system, and it breaks as soon as content exists on one platform but not another. Whether we like it or not, , and the links of the future cannot continue to be constrained by the limitations of workarounds like these. This is not good enough. also native apps are part of the future Instead, we need to take a fresh look at how we handle linking on the internet. A new approach to linking infrastructure is needed, adopting the best of what has worked in the past, but designed from the start to accommodate both websites and mobile apps, and flexible enough to adapt as future technologies come on the scene. “Deep linking” will be part of it, but what we need now goes far beyond that. Requirements for a New Linking Infrastructure Link routing is becoming too complex to handle locally on the user’s device. We are going to need something more powerful. Here are the eight critical aspects that this system must fulfill: A single, backwards-compatible address (URL) for each link that is valid everywhere links can be used. Delivers users to the requested destination (the basic definition of a ‘link’). Capable of handling both public destinations that should be discoverable, and private destinations that require authentication or authorization. Able to detect the device and environment details of the user, and intelligently route to the best-available experience (desktop web, mobile web, native app). This should be possible even if the preferred option is the native app, and it needs to be installed first. Centralized implementation of technical details (e.g., handling failure edge cases), preserving ease of creation and use for individual links. Updatable on the fly (including retroactively for existing links) to incorporate emerging technologies and new edge case failures as they are discovered. Analytics reporting (such as the HTTP referer header and UTM parameters) for the entire traffic pipeline. Able to accept additional, contextual link data (often implemented on the web as URL query parameters). In other words, a remote link service. An API for link routing. A dedicated link redirection server in the cloud. Hosted deep links. Whatever name you prefer, the reason for it is the same: as the mobile ecosystem becomes more fragmented, link routing is becoming too complex to handle locally on the user’s device. We are going to need something more powerful. How to Build a Linking Solution for Every Device Working on for the last two years, we have realized that a system like this actually does not need to existing link standards. Instead, it can mesh parts from all of them together, filling in the holes and adding glue between the pieces to complete the user experience. There are two basic components necessary to make this happen: Branch replace This determines which experience to use for each visitor. A remote, hosted service. . These allow each app or website to receive instructions from the remote service about what content to display. Local, client modules Part 1: Remote Service On the web, we never needed anything like this. Every web browser could handle its own routing based only on the data contained in the link URL, and there was no risk that it might be to load the experience. But that happens all the time on mobile — if the app isn’t installed, for example — and the result is frequently an error message. Not ideal. The primary purpose of this remote service is to take everything we know about incoming visitors (device type, app installation status, data from link opened, etc.), use that to determine the best possible user experience (website, App/Play Store, directly to app), and then send them there. unable Aside from the simplified routing process, there are several other advantages to implementing this routing logic remotely instead of on each device: It’s possible to follow users in places where they would usually disappear from view (e.g., when passing through the App or Play Stores). The most common example of this is “deferred deep linking,” or the ability to link directly to a piece of content inside a native app that isn’t yet installed. Links can be shorter, because the link address is a unique key for a set of data parameters stored on the remote service. In other words, you no longer need to cram all of the link data and behavior control information This makes it incredibly simple to do “contextual deep linking,” or the ability track things like where the link was clicked, who originally shared the link, and an almost unlimited amount of other custom data and tracking parameters in addition to the link destination. into the link itself. The remote service is also responsible for creating links. This involves accepting a set of data keys — the content locations on each platform, behavior control parameters, tracking and display configuration, plus other custom data — and returning a link address to reference them. That link is then valid for use anywhere, and if you pass up a system-wide unique ID for each piece of content, it’s even possible to deduplicate for data integrity when multiple links all point to the same thing. Part 2: Local Client Modules Once the remote service has determined which experience is best for a visitor, we need to communicate what should happen next. The app or website needs link data to know what content the visitor requested, and there are tracking and analytics housekeeping tasks to be done. All of this is handled by the local modules, which are packaged as platform-specific SDKs. Each SDK is optimized to best fit its programing language and environment, and is broadly responsible for the following tasks: Every single time the app or website is loaded/opened, find out if the remote routing service was involved (check if a link was clicked). Retrieve the data from that link and pass it over to the app or website for use. Track that all this happened, and report back to the remote service for analytics purposes. Links on the web have conditioned us to expect an immediate response, so our new links should be no different: all of this must take place instantly, which sounds easy, but can sometimes require careful choreography so as to remain invisible to the user. And of course the SDKs also facilitate easy link creation by wrapping convenient programming interfaces around calls to the remote service. A Snapshot of the System This is the platform we began building at in 2014. What is the result, and what have we learned so far? Branch We’re far past “deep linking” now. This is something much bigger. SDKs for app linking make perfect sense. There has never been a broadly-accepted, universal approach to app deep linking, so this is brand new territory and . On the other hand, web links already “just work,” so while the Branch web SDK technically be used as a standalone method for routing into websites, it’s almost always better to use a hybrid approach together with standard redirect rules. Any data returned from the remote link service is then used for added value rather than primary navigation. Branch now has an SDK for every major platform and development toolkit can As for the remote link service, Branch does use a remote backend for much of the heavy lifting, but in practice, we often have to lean on local web browsers for “last mile” functionality. Even if support for the remote service is eventually built directly into device operating systems, routing via web browser will always be necessary for full backwards compatibility. The end result is a linking infrastructure that does indeed fulfill all eight of the requirements above, and works better than anything else available, in almost every situation. The Branch platform has now been widely adopted by over 11,000 active apps, including . most of the top names in the industry But the most surprising thing we have learned is just how many ways things can go wrong. Apple and both try to pretend that mobile deep linking is a simple thing. A check-the-box, “nice to have” feature that can be implemented by following a few guides buried deep in the developer documentation for each platform. Unfortunately, this couldn’t possibly be further from the truth, and more importantly, it misses the true scale of the problem: if links are to be used everywhere, they need to The true complexity of how difficult this is to accomplish only becomes clear with much painful experimentation. Google work everywhere. First of all, there are numerous competing mobile deep link standards, all with different functionality and requirements for implementation: Note: iOS and Android together control 99.3% of the mobile market . Because of this, Branch has very limited support for other platforms, and they are omitted here for simplicity. Of course, none of these standards is supported on every platform or OS version: Facebook deserves special recognition for inventing an open-source deep linking standard that actually showed promise, and then completely abandoning it: Even within each platform, every web browser does things differently. This matters, because the majority of links clicks still happen in browsers, and every link routing system relies on browsers for at least some core functionality: Things get even messier outside the web browser category. So many other apps are capable of opening links that attempting to generate a comprehensive list would be an impossible task, but here are a few notable highlights: The Difficulty of Building Linking In-House You will want your app’s links to be part of the largest mobile content index in the world. First of all, building a linking system that can accommodate all these edge cases is a lot of effort. At Branch, our team spends every waking moment exclusively working on this, and we have learned that the devil is in the details. For example, what if you add app deep linking to all your emails, only to realize your unsubscribe link needs to go to the web on every platform? Now your emails are broken even worse than they were before. And even once the infrastructure is built, ecosystem changes happen so frequently that nothing can be relied upon to “just work” in the future. Keeping up to date with ever-changing standards is a full time job you don’t want, because you already have more exciting things to do. But more importantly, there is a critical final piece we haven’t discussed yet: . App content doesn’t show up in web searches, and the best workaround Google has developed involves (yet again) the hack of tying apps and websites more closely together. As the app ecosystem continues to develop, this cannot be our best answer to the problem of content discoverability. Just like the vast majority of us use Google for web searches without a second thought (how many other search engines have become their own verb?), you will want your app’s links to be part of the largest mobile content index in the world. This index is Branch, and it is growing every day. search For better or worse, . But no advancement comes without costs, and the move to apps means that links — a core concept of the internet — have taken a big step backward. It’s up to us as developers to find a solution that brings back the openness of the web, otherwise apps will be doomed to live inside walled gardens forever. the age of the native mobile app is here Appendix: What Could Go Wrong? This is a pretty fundamental adjustment to the way we’ve grown up handling links on the web, so of course there are some valid objections to address. What if the service goes down? I won’t know where to send my users! This is probably the biggest risk of using a centralized system for link routing. But in reality, we already rely on remote services like DNS and CDNs for much of the modern internet. The benefits of these systems outweigh the risks, and link success rates over 99.9% (meaning less than one failure per 1000 attempts) are well within reach. What about generating links without an active network connection? When this happens, whether due to network congestion or simply because an extra network call is unwanted, all the link data can be encoded into a long-form URL and then passed up to the remote service the first time that link is loaded. The result is a much longer link address, but the same behavior. Shortened link URLs are harder to read. One of the great things about web links is that the addresses seen by users often follow a structure. In fact, this is so common that it is . Structuring things this way was originally reflective of the underlying filesystem of the server where the site was hosted, but has already started to break down with the rise of URL shortener services like Bit.ly and Goo.gl. The Branch platform (along with knockoff attempts like Firebase Dynamic Links) have used a similar short URL approach, because there is no guarantee that content inside a mobile app will be structured the same way as the corresponding website. This frees links from being tied to the technical implementation of any single platform, but nothing prevents building a structure into the addresses of links, and the Branch system already allows customization of these addresses if desired. path/to/content taken as a best practice How does this fit with Universal Links and App Links? Even though Apple and Google intended these standards to more closely tie apps and websites — the opposite goal from a comprehensive linking infrastructure focused on flexibility — it’s easy to incorporate them into the system. For our purposes, they function as pre-authorized shortcuts to speed up the user experience.

REAL LINKS

reallinks.io

-- employees

Since n.d.

COMPANY RANKING

REAL LINKS

EVERGREEN INDEX #9096

Representing this company? Click here to claim and customize this page!

Real Links WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

REAL LINKS

reallinks.io

-- employees

Since n.d.

COMPANY RANKING

REAL LINKS

EVERGREEN INDEX #9096

RELATED COMPANIESRANK

STORIES ABOUT REAL LINKS

Representing this company? Click here to claim and customize this page!

Real Links WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!