UPCORE

upcore

How Do Signal Constraints Affect Bayesian Persuasion in Multi-Phase Trials?

¿Kunjamsa Constreñimientos de Señal ukax Persuasión Bayesiana ukarux walja fase ukan yant’awinakapanx jan walt’ayi?

¿Cómo afectan las restricciones de señal a la persuasión bayesiana en ensayos multifásicos?

محدودیت‌های سیگنال چگونه بر متقاعدسازی بیزی در آزمایش‌های چند مرحله‌ای تأثیر می‌گذارند؟

Bagaimana Kendala Sinyal Mempengaruhi Persuasi Bayesian dalam Uji Coba Multi-Fase?

信号制約は多段階試験におけるベイズ説得にどのように影響しますか?

Bagaimanakah Kekangan Isyarat Mempengaruhi Pujukan Bayesian dalam Percubaan Berbilang Fasa?

Hoe beïnvloeden signaalbeperkingen de Bayesiaanse overtuiging in multifase-onderzoeken?

Ako obmedzenia signálu ovplyvňujú Bayesovské presviedčanie vo viacfázových skúškach?

Hur påverkar signalbegränsningar Bayesian Persuasion i flerfasförsök?

Paano Naaapektuhan ng Signal Constraints ang Bayesian Persuasion sa Multi-Phase Trials?

Як обмеження сигналу впливають на байєсівське переконання в багатофазних дослідженнях?

Izithiyo Zesiginali Zikuthinta Kanjani Ukuthonya Kwe-Bayesian Ezivivinyweni Zezigaba Eziningi?

Open Innovation is the Cornerstone of Your Startup’s Success

Trump v. United States Court Filing, retrieved on July 1, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part in this filing here. This part is 15 of 21. V Separate from its official-acts immunity, the majority recognizes absolute immunity for “conduct within [the President’s] exclusive sphere of constitutional authority.” Ante, at 9. Feel free to skip over those pages of the majority’s opinion. With broad official-acts immunity covering the field, this ostensibly narrower immunity serves little purpose. In any event, this case simply does not turn on conduct within the President’s “exclusive sphere of constitutional authority,” and the majority’s attempt to apply a core immunity of its own making expands the concept of “core constitutional powers,” ante, at 6, beyond any recognizable bounds. The idea of a narrow core immunity might have some intuitive appeal, in a case that actually presented the issue. If the President’s power is “conclusive and preclusive” on a given subject, then Congress should not be able to “ac[t] upon the subject.” Youngstown Sheet & Tube Co. v. Sawyer, 343 U. S. 579, 638 (1952) (Jackson, J., concurring). In his Youngstown concurrence, Justice Robert Jackson posited that the President’s “power of removal in executive agencies” seemed to fall within this narrow category. Ibid., n. 4. Other decisions of this Court indicate that the pardon power also falls in this category, see United States v. Klein, 13 Wall. 128, 147 (1872) (“To the executive alone is in trusted the power of pardon; and it is granted without limit”), as does the power to recognize foreign countries, see Zivotofsky v. Kerry, 576 U. S. 1, 32 (2015) (holding that the President has “exclusive power . . . to control recognition determinations”). In this case, however, the question whether a former President enjoys a narrow immunity for the “exercise of his core constitutional powers,” ante, at 6, has never been at issue, and for good reason: Trump was not criminally indicted for taking actions that the Constitution places in the unassailable core of Executive power. He was not charged, for example, with illegally wielding the Presidency’s pardon power or veto power or appointment power or even removal power. Instead, Trump was charged with a conspiracy to commit fraud to subvert the Presidential election. It is true that the detailed indictment in this case alleges that Trump threatened to remove an Acting Attorney General who would not carry out his scheme. See, e.g., App. 216–217, Indictment ¶¶74, 77. Yet it is equally clear that the Government does not seek to “impose criminal liability on the [P]resident for exercising or talking about exercising the appointment and removal power.” Tr. of Oral Arg. 127. If that were the majority’s concern, it could simply have said that the Government cannot charge a President’s threatened use of the removal power as an overt act in the conspiracy. It says much more. The core immunity that the majority creates will insulate a considerably larger sphere of conduct than the narrow core of “conclusive and preclusive” powers that the Court previously has recognized. The first indication comes when the majority includes the President’s broad duty to “‘take Care that the Laws be faithfully executed’” among the core functions for which a former President supposedly enjoys absolute immunity. Ante, at 20 (quoting Art. II, §3). That expansive view of core power will effectively insulate all sorts of noncore conduct from criminal prosecution. Were there any question, consider how the majority applies its newly minted core immunity to the allegations in this case. It concludes that “Trump is . . . absolutely immune from prosecution for” any “conduct involving his discussions with Justice Department officials.” Ante, at 21. That conception of core immunity expands the “conclusive and preclusive” category beyond recognition, foreclosing the possibility of prosecution for broad swaths of conduct. Under that view of core powers, even fabricating evidence and insisting the Department use it in a criminal case could be covered. The majority’s conception of “core” immunity sweeps far more broadly than its logic, borrowed from Youngstown, should allow. The majority tries to assuage any concerns about its made-up core immunity by suggesting that the Government agrees with it. See ante, at 34. That suggestion will surprise the Government. To say, as the Government did, that a “small core of exclusive official acts” such as “the pardon power, the power to recognize foreign nations, the power to veto legislation, [and] the power to make appointments” cannot be regulated by Congress, see Tr. of Oral Arg. 85– 87, does not suggest that the Government agrees with immunizing any and all conduct conceivably related to the majority’s broad array of supposedly “core” powers. The Government in fact advised this Court to “leav[e] potentially more difficult questions” about the scope of any immunity “that might arise on different facts for decision if they are ever presented.” Brief for United States 45. That would have made sense. The indictment here does not pose any threat of impermissibly criminalizing acts within the President’s “conclusive and preclusive” authority. Perhaps for this reason, even Trump discouraged consideration of “a narrower scope of immunity,” claiming that such an immunity “would be nearly impossible to fashion, and would certainly involve impractical line-drawing problems in every application.” Brief for Petitioner 43–44. When forced to wade into thorny separation-of-powers disputes, this Court’s usual practice is to “confine the opinion only to the very questions necessary to decision of the case.” Dames & Moore v. Regan, 453 U. S. 654, 661 (1981). There is plenty of peril and little value in crafting a core immunity doctrine that Trump did not seek and that rightly has no application to this case. Continue Reading Here. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.
This court case retrieved on July 1, 2024, supremecourt.gov is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. Trump v. United States Court Filing, retrieved on July 1, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part in this filing here. This part is 15 of 21. Trump v. United States Court Filing, retrieved on July 1, 2024, is part of HackerNoon’s Legal PDF Series . You can jump to any part in this filing here . This part is 15 of 21. HackerNoon’s Legal PDF Series here V Separate from its official-acts immunity, the majority recognizes absolute immunity for “conduct within [the President’s] exclusive sphere of constitutional authority.” Ante, at 9. Feel free to skip over those pages of the majority’s opinion. With broad official-acts immunity covering the field, this ostensibly narrower immunity serves little purpose. In any event, this case simply does not turn on conduct within the President’s “exclusive sphere of constitutional authority,” and the majority’s attempt to apply a core immunity of its own making expands the concept of “core constitutional powers,” ante, at 6, beyond any recognizable bounds. The idea of a narrow core immunity might have some intuitive appeal, in a case that actually presented the issue. If the President’s power is “conclusive and preclusive” on a given subject, then Congress should not be able to “ac[t] upon the subject.” Youngstown Sheet & Tube Co. v. Sawyer, 343 U. S. 579, 638 (1952) (Jackson, J., concurring). In his Youngstown concurrence, Justice Robert Jackson posited that the President’s “power of removal in executive agencies” seemed to fall within this narrow category. Ibid., n. 4. Other decisions of this Court indicate that the pardon power also falls in this category, see United States v. Klein, 13 Wall. 128, 147 (1872) (“To the executive alone is in trusted the power of pardon; and it is granted without limit”), as does the power to recognize foreign countries, see Zivotofsky v. Kerry, 576 U. S. 1, 32 (2015) (holding that the President has “exclusive power . . . to control recognition determinations”). In this case, however, the question whether a former President enjoys a narrow immunity for the “exercise of his core constitutional powers,” ante, at 6, has never been at issue, and for good reason: Trump was not criminally indicted for taking actions that the Constitution places in the unassailable core of Executive power. He was not charged, for example, with illegally wielding the Presidency’s pardon power or veto power or appointment power or even removal power. Instead, Trump was charged with a conspiracy to commit fraud to subvert the Presidential election. It is true that the detailed indictment in this case alleges that Trump threatened to remove an Acting Attorney General who would not carry out his scheme. See, e.g., App. 216–217, Indictment ¶¶74, 77. Yet it is equally clear that the Government does not seek to “impose criminal liability on the [P]resident for exercising or talking about exercising the appointment and removal power.” Tr. of Oral Arg. 127. If that were the majority’s concern, it could simply have said that the Government cannot charge a President’s threatened use of the removal power as an overt act in the conspiracy. It says much more. The core immunity that the majority creates will insulate a considerably larger sphere of conduct than the narrow core of “conclusive and preclusive” powers that the Court previously has recognized. The first indication comes when the majority includes the President’s broad duty to “‘take Care that the Laws be faithfully executed’” among the core functions for which a former President supposedly enjoys absolute immunity. Ante, at 20 (quoting Art. II, §3). That expansive view of core power will effectively insulate all sorts of noncore conduct from criminal prosecution. Were there any question, consider how the majority applies its newly minted core immunity to the allegations in this case. It concludes that “Trump is . . . absolutely immune from prosecution for” any “conduct involving his discussions with Justice Department officials.” Ante, at 21. That conception of core immunity expands the “conclusive and preclusive” category beyond recognition, foreclosing the possibility of prosecution for broad swaths of conduct. Under that view of core powers, even fabricating evidence and insisting the Department use it in a criminal case could be covered. The majority’s conception of “core” immunity sweeps far more broadly than its logic, borrowed from Youngstown, should allow. The majority tries to assuage any concerns about its made-up core immunity by suggesting that the Government agrees with it. See ante, at 34. That suggestion will surprise the Government. To say, as the Government did, that a “small core of exclusive official acts” such as “the pardon power, the power to recognize foreign nations, the power to veto legislation, [and] the power to make appointments” cannot be regulated by Congress, see Tr. of Oral Arg. 85– 87, does not suggest that the Government agrees with immunizing any and all conduct conceivably related to the majority’s broad array of supposedly “core” powers. The Government in fact advised this Court to “leav[e] potentially more difficult questions” about the scope of any immunity “that might arise on different facts for decision if they are ever presented.” Brief for United States 45. That would have made sense. The indictment here does not pose any threat of impermissibly criminalizing acts within the President’s “conclusive and preclusive” authority. Perhaps for this reason, even Trump discouraged consideration of “a narrower scope of immunity,” claiming that such an immunity “would be nearly impossible to fashion, and would certainly involve impractical line-drawing problems in every application.” Brief for Petitioner 43–44. When forced to wade into thorny separation-of-powers disputes, this Court’s usual practice is to “confine the opinion only to the very questions necessary to decision of the case.” Dames & Moore v. Regan, 453 U. S. 654, 661 (1981). There is plenty of peril and little value in crafting a core immunity doctrine that Trump did not seek and that rightly has no application to this case. Continue Reading Here. Continue Reading Here . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on July 1, 2024, supremecourt.gov is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on July 1, 2024, supremecourt.gov is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. supremecourt.gov

How the Majority of the Supreme Court Recognizes Absolute Immunity

Quality and usability of a data stack might not be what a startup founder had in mind at the beginning of their business journey. But let’s be clear: when you’re overwhelmed by data, when teams lack the tools to extract the necessary data to make informed decisions, and investors can’t get a clear picture of your business health, it’s already too late. The common misconception is that data is complex and abstract, and only corporations need to deal with it. Yet, every tech startup creates a massive amount of data with each click, transaction, and interaction. This data ranges from payment transactions, client databases, and marketing pipelines to employee birthdays. As companies grow and scale, they produce even more data that requires new tools and professionals to manage it. Interestingly, big tech companies work with data warehouses, while startups may only use Excel sheets shared on WhatsApp; still, at their core, both corporations and startups handle data in similar ways. The question then is: how do startups start doing the same? From managing a data warehouse at a tech corporation with over ten thousand employees and working on my own startups, I've learned that regardless of the volume of data and business requirements, startups need to think big from the start. Still, there is no universal solution for every business case, but the core principles that all big tech companies adhere to can and should be adopted by startups. Doing so will cultivate a scalable data culture at every stage of business growth. What data do we have and who is responsible for it? Supporting a culture of data responsibility from the beginning is crucial. Even though data is often interdepartmental and responsibilities tend to fluctuate in startups, it’s essential to understand where data is stored and who owns it. The owner of these datasets should be responsible for their storage, usage, and quality. For instance, in a situation where a product manager calculated the unit economics, but a finance team doesn’t have access to the expenses and a sales team insists that more sales were made, the role of the data owner is to create a clear path to resolve the problem. A common misconception is that tech teams should be entirely responsible for data. This creates situations when data is led by technology requirements, rather than business needs. When tech teams prioritise technical aspects like data storage, security, and infrastructure, they might not fully grasp the true needs and objectives of the business. As a result, the data analysis and interpretation may become limited to what the technology allows, rather than what the business truly requires. This is not the path to becoming a data-driven company. It might sound counterintuitive, as all the data lives inside the data stack, but business teams should be data owners and stewards. At the end of the day, the point of data management is serving business needs. The easiest way to start is to divide your data between business functions, such as sales (CRM, marketing data), product (unit economics, backlogs, road maps), and finance (financial reports, budgeting), etc. Then, assign a data-owner from each business function for each dataset. To prevent these data responsibility roles from getting lost during rapid growth and scaling, make sure to move the roles accordingly. How do we store the data? The main rule here is if you don’t keep all the data in corporate software, you don’t have the data at all. As a simple example, when a client is ready to buy a product with a 30% discount that was discussed with your sales manager in a private message, who is now on vacation, and there’s no information in a CRM system, you might face some issues. Ensure that all important data is stored and accessible for the right team members. First, set up shared file storage to support collaboration among team members. Cloud storage might be your best option, as it's an accessible, scalable, and usually cost-effective solution for managing your data. Even when you introduce new software and tools, such as document management and content management systems, CRM, and ERP, cloud storage will remain a place where team members can store data like reports, presentations, or documentation. Keep both the raw data (data that has not been processed for use) and processed data — it will help to avoid situations where something went wrong and a team needs to re-do the analytics or sync data between departments. Remember, data can be qualitative but not always usable. Corporations typically adopt a ‘store it all’ approach to data storage, but for startups where resources are limited, this task can be daunting. It is hard to predict what data might be of any use in the future, but thoughtful planning and looking into best market practices might provide some insights. If you find your startup is struggling with storage costs, consider introducing a recurring data demand review. Over time, it might turn out that some data that was considered useful is not anymore. You can simply start by checking data that wasn’t used for many months, but remember to align any decision to delete or archive data with the respective owners. If it doesn’t help, it might be a good time to seek a better tool with superior data compression and tailored pricing options. How do we secure the data? Data security is undoubtedly one of the most important goals for any tech startup, as well as the hardest one to achieve. Just imagine that a finance team member stores reports on their personal computer, and a sales intern has access to the full clients' database from day one — sounds like a recipe for disaster. While full data security is mostly an unrealistic objective, implementing a company culture with data security at its core could potentially minimise major data leaks or damage. Once you have chosen your data storage software, and data owners and stewards have been assigned, it’s now time to discuss who sees what and how to get access to data. Choose a team member responsible for assigning data access. For small startups, it is probably going to be a founder, but as the company scales, a decentralised approach may be more suitable. It’s easier to maintain access permissions when they are granted to roles rather than team members, which makes it easier to transfer access between employees in case of any changes. Moreover, the data owners should know the platforms' backup policies by heart. For the most sensitive data, a manual backup must be applied. The restoration of your company's customer database after a website breach could depend entirely on a single checkmark in the site settings. How do we keep the data organised? It’s likely that, at some point, data owners will be busy with more pressing matters. Their focus will move away from the data stack, leaving it without any support. That’s why at the very beginning, it’s essential to adopt the right approach to data management. Otherwise, while scaling and growing, a startup could be overwhelmed by data, and produce duplicate reports and analytics based on incorrect data. The more unmanaged data you have, the less usable it becomes. Prioritising is key here. At every stage of a company’s development, choose the right approach to data governance that is aligned with your current needs and capabilities. Data governance is a collection of policies, processes, roles, metrics, and standards for effective and efficient use of information. Consider Introducing a data steward role in your company. At the very beginning, it’s probably going to be a founder or CEO, who will set up data governance and oversee the beginning of cross-functional implementation. However, shortly after, it’s better to appoint a dedicated team member to facilitate its development, such as providing data owners with guidance for data storage, security, management, and best practices exchange. Make sure that the policies are followed by them. Otherwise, investigate the cause and make the required changes. How do we know where to find the data and what does it actually mean? As the volume of your data increases, so does the time spent searching for the right data. For example, when a commercial team needs to report on a company’s monthly results in retrospect to the last two years, it might be a stressful task to look through all the data, if it wasn’t in order at the beginning. That’s where a knowledge base will be of help. Even though documentation might seem overwhelming and unnecessary when everyone is juggling numerous urgent tasks, once done, it will be a significant time-saver in the future. Corporations usually use a data catalogue software, a kind of data library where data is well-organised and securely stored. For startups, the solution will probably be extensive — any knowledge management software, such as Confluence or Notion, will be more than enough. Start with writing down what software you use, what data you have, who is responsible for it, how to get access etc. Next, create a data analytics glossary that will help the team to speak the same language and work on cross-functional tasks more effectively. Make sure the terminology is also used in file naming and routes to them; these small implementations will sufficiently reduce time spent on searching and exchanging files, as well as on the documentation itself. Assess the complexity of documentation based on the business structure, size, and amount of data possessed. For instance, a glossary listing the data collected and the most crucial reports with their data owners would suffice for small low-tech businesses. For high-tech startups, data flow, entity relationship diagrams, deployment diagrams, and metadata layers can be beneficial for ensuring data quality and usability. A good practice is to create manuals for reports and analytics. This could be step-by-step guides with examples or video recordings on how to create them. Pay particular attention to the alignment between departments in terms of reports. In case the operational team’s members approach the finance team and ask for the same numbers but in different formats and variations, it could lead to a mess inside both departments as well as unnecessary time consumption. This issue can easily be avoided by agreements between departments on what type and format of data should be provided, timeframes, and responsibility for the delivery team members. How do we handle the data? By fostering a data-driven culture within a startup, you create an understanding for every team member that data analytics is a task that should be taken seriously. Data governance must become an essential element of business, from choosing a data analytics tool to establishing file naming principles. Let’s consider some more useful tips and tricks for how to handle the data better: . If there’s a pattern of repeatedly emerging questions or situations, such as team members wondering where reports live or how to calculate a newly introduced metric — document it. It’s better to address such questions right away than find out later that your company uses at least two different formulas to calculate the LTV of its customer. Documentation . When creating an extended report, start with its prototype: discuss the essential requirements, do a quick analysis, approve a layout and design, and then move to the report creation. This process will help to avoid situations where a report that took a month to create turns out to be unacceptable. Reports prototyping . Always brief before data processing. When creating a report using data you’re not an owner of, make sure you interpret it correctly. Briefing . Cultivate a culture of peer reviews to validate data and its usability. Encourage asking questions before doing anything and align priorities with the overall business goals rather than individual or department goals.’ Peer review For any tech startup, the data stack is an essential part of the business. While some big tech practices might look unnecessary and even harmful (for example, if the growth speed is more important than the long-term perspective.) But fostering a data-driven culture from the very beginning can pave the way to success and help turn your startup into a fast-scaling company. Just remember: it’s a lifelong journey, and following the Pareto principle will help you on your way to becoming a truly data-driven company.

How to handle your startup data like a big tech

The simple query service (SQS) was one of the first services AWS offered. It's a managed queuing service that lets you take pressure from your downstream services. You put your items on the queue, and other services can pull them whenever they have the capacity to work on them. It's a managed service, so you don't have to install or maintain the software yourself; you just configure a queue and start pushing to and pulling from it. So SQS is very simple to get started with. As with all services on AWS, issues can crop up while using SQS because it's not always obvious what every service can and cannot do. But fear not, for this article aims to help you solve the most common ones as quickly as possible. Ready to fix your queues? Then let's dive in! 1. Java SDK -- Cannot Receive Message Attributes You tried to get messages with attribute without telling the SDK the attribute name. To fix this you need to call receiveMessage with the following parameter: sqs.receiveMessage( receiveMessageRequest .withMessageAttributeNames("myAttribute") ).getMessages() This way, the SDK knows that it should include the attributes you care about. For background, AWS services in general, and SQS in particular, are optimized to lower traffic because you pay for all data you want to get out of AWS. If you used an SQS queue from outside of AWS, you would like to make sure you only get the data you use to save money and increase throughput. The AWS SDK lets you define which attributes of the message you need to get this optimization going. But later, when you access attributes, you have to keep in mind which you have fetched; otherwise, you will find something akin to a null-pointer exception: accessing data that isn't there. 2. SNS Topic Not Publishing to SQS You tried to publish to SQS from an SNS topic that doesn't have permission. To fix this, you need to allow SQS to the SendMessage action from the SNS service principal. Here is an example policy: { "Statement": [{ "Sid": "Allow-SNS-SendMessage", "Effect": "Allow", "Principal": { "Service": "sns.amazonaws.com" }, "Action": ["sqs:SendMessage"], "Resource": "arn:aws:sqs:us-east-2:444455556666:MyQueue", "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:sns:us-east-2:444455556666:MyTopic" } } }] } This problem is based on the misconception that SNS topics are deployed in your account. You might expect your account to act as the principal here, but the SNS service itself acts as the principal. So, you end up with your account getting permission it can't use and the actual principal being locked out. AWS preconfigures all services with minimal access rights, usually none at all. This helps with security because you don't accidentally deploy something the whole world can access. In day-to-day development work, this is often a bit cumbersome. You add a new feature, and suddenly you need to configure new permissions, so a simple one-liner requires you to write JSON documents in a completely different place. Well, that's the price we pay for safety. 3. Access Denied to SQS via AWS SDK You tried to access SQS with a role or user that hasn't any permissions. To solve this, initialize the SDK with an account set up with the required SQS permissions. You can do so in the IAM console. Again, AWS is all about keeping your data safe. So it will lock down all your services by default so that nobody can access anything. If you want to give access to a service, you have to assign a role to it and permit this role to do its work. You can simply use admin permissions for development purposes inside a development AWS account, so you don't have to change your roles when you need different permissions. But in a production environment, you should give every service minimal permission. This way, a compromised service won't expose your whole infrastructure. 4. Prevent Adding Duplicate SQS Messages You're adding messages to a queue and don't know if you already added a message. This issue can't be solved with SQS; you would have to either use another service or filter messages before adding them to the queue. SQS isn't made for such a use case, so you can't prevent a queue from accepting items it already holds. If you have this constraint, you need to choose a more complex service like DynamoDB, which allows you to mark documents as unique. Step Functions might also be an option here, but this depends mainly on your use case. 5. In-Flight Messages Your consumers pulled messages without deleting them or increasing the timeout. To fix this, you need to call deleteMessage with your receipt handle. sqs.deleteMessage({ QueueUrl: 'STRING_VALUE', ReceiptHandle: 'STRING_VALUE' }); The idea here is that your consumer can delete a message when it is finished processing it. If a consumer crashes before completing their work, the message remains in the queue, and eventually, another consumer can process it. So, the consumer pulls a message, processes it, deletes it, and pulls the following message. 6. FIFO Blocks the Queue You configured a queue as FIFO, and a message blocks the whole queue. To mitigate this issue, group your messages with message group IDs; messages will only block those in the same group. If you have a queue with many different types of messages and all of them have the same group ID, this can become a maintenance nightmare quickly. Make sure you group messages into smaller batches to lower the likelihood of blocking the whole queue when things go wrong. Summary SQS is a straightforward service. You can see it as a temporary database. If you need to put data somewhere to be processed later, SQS is the way to go. Every service on AWS, an SQS queue, and all the other services in your stack using that queue will be configured with minimal permissions, leading to access issues. So, make sure you get your IAM policies set up correctly before deploying to production. Admin roles might help when developing, but they're a security nightmare when used in production, so you need to watch IAM policies when deploying! If you need more control about what gets in or out of your queue, Step Functions or DynamoDB might be a better bet. Monitor SQS queues with Dashbird Dashbird in your AWS account; no extra config is needed. Everything will be evaluated according to , so you see right away if you're following best practices. automatically monitors SQS queues the Well-Architected Framework ; no credit card is required. See our product tour . You can try Dashbird now here At Dashbird, we understand that serverless's core idea and value is to . That's exactly what we provide. We give the focus back to developers to only think about the ,and not be distracted by debugging and alarm management or to worry about whether something is working or not. focus on the customer and the ability to avoid heavy lifting end customer

5 Common Amazon SQS Issues

from Google is the new ranking signal in the town expected to arrive with full force in 2021. It will join the ‘page experience signal’ to promote the websites for developing better user experience characteristics like mobile-friendliness, loading speed, etc. Core web vitals But before taking a deep dive into the core web vitals, it is important to have a quick understanding of the page experience signals first to develop a better picture of the core topic. “The role of page experience signals is to evaluate and measure the experience of users while interacting with a website page.” The data collected through page experience signals can be analyzed and put into action to optimize the site for improved performance so that the users can have a seamless experience while browsing around the website. It is a great way for a business to strengthen its bond with the target audience and build long-lasting and trustworthy relationships. Although these signals are not just limited to assist businesses in building concrete relationships. Websites that will take effective actions from page experience signal metrics shall have a better chance to shine in the search results because Google intends to create an improved web experience environment for the users. The page experience signal metrics are taken into account when it comes to ranking a website on Google search engine result pages. As of now, the “page experience signal” includes the following metrics- Mobile-friendliness Secure browsing HTTPS-security Intrusive interstitial If necessary implementations are observed to improve the position of these aforesaid metrics for a website, then it will help to push the URL to a more competitive spot on the search engine result pages. However, these metrics are not detailed or comprehensive which sometimes do not provide a clear direction to the website owners. Core web vitals somewhere fill this gap as they are more detailed and provide actionable insight. So, how do core web vitals work and how can they help the websites? Let’s find it out. Understanding All 3 Core Web Vitals As already discussed before, the core web vitals is not a new category of ranking signal, but an addition to Google’s existing ranking factor- “page experience signal”. The core web vitals will stage the page experience signal to the next level with its informative metrics and help the owners, developers, or marketers to navigate the opportunities for the improvement of website experience. So, the three core web vitals are as follows: LCP (Largest Contentful Paint) FID (First Input Delay) CLS (Cumulative Layout Shift) LCP (Largest Contentful Paint) The usual speed measurement metrics like- Time to first byte (TTFB) or First Contextual Paint (FCP) are not the most effective ways for highlighting the web pages’ speed because they don’t correspond to what a user sees on the screen while interacting with the page. When it comes to website speed, then what matters the most is- how much time it is taking for a user to interact with the largest contents of the page. This is where LCP comes to the rescue. LCP measures the time a web page takes to load from the users’ perspective. To put it in other words, it determines the time consumed for loading the largest content (text, image, or video block) on the screen right after the user has requested the URL. So, how to know if the LCP score of the website is good, average, or bad? According to the specific , the LCP speed of the website can be categorized into any of the following three- LCP guidelines of Google (if the largest content on the page loads within 2.5 seconds) Good (if the largest content on the page takes more than 2.5 seconds but less than 4 seconds to load) Needs Improvement (if the largest content on the page takes more than 4 seconds to load) Poor source: web.dev Hence, a website’s goal should be to hit the LCP within 2.5 seconds for every page that it has. FID (First Input Delay) First Input Delay is another core web vital that calculates the time taken by the website to respond to the interaction request of the user. These interactions with a website can be anything like- selecting an option from the menu, putting the email address into a field, choosing the newsletter subscription offer, etc. So, how to know if the FID score of the website is good or not? According to the specific , the FID speed of the website can be categorized into any of the following three: FID guidelines of Google (If the site response time is less than 100 milliseconds) Good (If the site response time is more than 100 milliseconds but less than 300 milliseconds) Needs Improvement (If the site response time is more than 300 milliseconds) Poor source: web.dev FID measures the time it takes to do something on a web page, hence, it is also a speed score. Although it goes one step ahead as it evaluates the time consumed for the users to execute something on the website. CLS (Cumulative Layout Shift) An unexpected change in the web page layout leads to a very bad user experience. For example, if a user is reading a blog on a website but the text shifts to another place without any warning, then it will create an annoying experience for the users. Also, the unexpected movement can happen for not only text but for other elements on the page also such as links, images, fields, or call-to-action buttons. It is not at all good for the reputation of the website. Hence, it is important that such issues related to the unexpected movement of content are resolved. For this purpose, the third core web vital of Google- CLS is here to guide because it evaluates how often such unexpected movements are being faced by the users. CLS calculates the stability of a web page layout. So, how to know if the CLS score of the website is good or not? According to the specific , the CLS score of the website can be categorized into any of the following three: CLS guidelines of Google (If the CLS score is less than 0.1) Good (if the CLS score is more than 0.1 but less than 0.25) Needs Improvement (if the CLS score is more than 0.25) Poor source: web.dev So, if a website wants to present a good user experience, then it should have a CLS score of less than 0.1. Tools for measuring Core Web Vitals There are six tools from Google as of now that can help in measuring core web vitals. These tools are easy to use and allow quick evaluation of the LCP, FID, and CLS position of the website. Check them out below- PageSpeed Insights Chrome UX Report Search Console Chrome DevTools Lighthouse Web Vitals Extension source: web.dev : Anybody can visit the tool, insert the web page URL, and click on the “analyze” button. That’s it. In just three easy steps, the core web vitals data will be generated for both web and mobile interface along with the suggestions that can help to improve the page experience. PageSpeed Insights PageSpeed Insights : The for Google Chrome can be downloaded to generate the core web vitals information. It was recently updated to version 6.0 that has introduced additional audits and new metrics like TBT for a detailed diagnosis of web page performance. It also helps in providing opportunities to reform the UX of the website. Lighthouse lighthouse extension : , also known as CrUX is a public dataset that has been made from various samples collected from chrome users’ browsing experience on the web. This report measures all three core web vitals and reports the real-world information instead of the lab data which is very useful. Chrome UX Report Chrome UX report : Chrome DevTools is great for website owners to find and restore visual instability or unexpected layout shifts issues present on the web page. The investigation for such issues on the pages can be done from the new in the performance panel of the tool. It also calculates TBT- Total Blocking Time which can assist in improving FID. Chrome DevTools experience section : for Chrome measures all three core web vitals- LCP, FID, and CLS in real-time. Web Vitals Extension Web Vitals Extension : The tools discussed above lack one thing or another that prevents them to be labeled as a one-stop solution for rectifying all the user-experience related issues, but this is where the Google Search Console joins the game. It has a lot of features that can assist in the foolproof improvement of page experience. The tool analyzes every page of the website and detects the ones that are having problems related to LCP, FID, or CLS metrics. It also lists out the opportunities for improvement to allow website owners and developers to implement necessary solutions. Google Search Console All three core web vitals can be evaluated in Javascript  by using standard web APIs. The is the most simple way to calculate each metric of core web vitals. Measuring each metric with web-vitals JavaScript library is as simple as calling a single function: web-vitals JavaScript library {getCLS, getFID, getLCP} ; { body = .stringify(metric); (navigator.sendBeacon && navigator.sendBeacon( , body)) ||
      fetch( , {body, : , : });
}

getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics); import from 'web-vitals' ( ) function sendToAnalytics metric const JSON // Use `navigator.sendBeacon()` if available, falling back to `fetch()`. '/analytics' '/analytics' method 'POST' keepalive true However, it is recommended to go with the six tools and extensions mentioned above so that you don’t have to pull any extra effort in writing codes. The next important thing to discuss is- how optimized images improve the core web vitals of a website and SEO. Let’s discuss this. Role of Optimized Images in Core Web Vitals The most important thing for improving the page experience quality of a website involves- image optimization. The large image placed on the homepage of a website is often the LCP (Largest Contentful Paint) and if it is not optimized, then it will affect the LCP score because of slow loading. It will not serve a good user experience. In image optimization, the objective should always be to compress it to the right size and right format without affecting the quality of the image. Optimized images not only improves the loading time of a web page but also provides the much-needed SEO advantage. Implementing the next-gen image formats like AVIF and WebP can be observed during image optimization as these formats bring the best quality in low-size. The good news is that the majority of the popular browsers extend support to these modern formats. All three core web vitals have one single objective- to improve the page experience factor by focusing on the website’s speed and performance and optimized images are the best solution to gain the advantage. Although, the organizations often fail to find the balance in size and format while optimizing the images. This problem will become a hurdle when the companies will optimize for the core web vitals. For this purpose, the experienced development team at can provide a wide range of robust solutions for optimizing images. The ImageEngine team puts service into the application that takes care of converting the images to next-gen image formats (having the best quality at low size) like WebP, AVIF, etc. and then serving the same to the popular browsers. ImageEngine image CDN Wrapping it Up: How ImageEngine will Help Boost SEO optimizes the images to provide companies of all sizes with a competitive SEO advantage. The in-house experts understand how the search engine behaves and interprets the image when ranking the URLs. ImageEngine Our image CDN service reduces the loading time of the website which initiates a string of events. When the site performance and speed are elevated, then the bounce rates are reduced. It is important to control the bounce rates. According to Google if the loading time is increased from 1 second to 3 seconds, then the bounce rate will shoot up to 32% and if the loading time is increased from 1 second to 6 seconds, then the bounce rate will jump to 106%. This is bad not only for the business but for search engine ranking also. Once the bounce rates are under control, then the website engagement and user experience progress to improve the probability of additional conversions. The end result is a successful business as well as a better ranking on the search engine. This is what the team at ImageEngine strives to achieve so that your business grows with a perfect blend of technology and experience. Previously published at https://imageengine.io/blog/improve-core-web-vitals-with-imageengine

Core Web Vitals: How To Improve To Rank Higher On Google And Succeed In Your Business 

This is Part 3 of 6 in the Let’s Explore ARK Core series which documents the development of the next major release of ARK Core, alongside some tips & tricks on how to get started with contributing and building your next idea today. Introduction In the and of this series, we gave a rough overview of how the Core infrastructure and application bootstrapping process was revamped. Today we’ll learn what inside of Core are, why they were introduced and what their job is to keep Core running. Part 1 Part 2 services ARK Core v3.0 Github Repository What is a service? Before starting we should set the stage by defining what a service inside of Core is. In simple terms, a service is a self-contained feature that only exposes a small chunk of the total business logic that makes up Core. For example, a log service, cache service, database service, transaction service, etc. — all of those are important building blocks of Core and should be easy to modify, maintain and test. Why were services introduced? Services aren’t actually all new in Core 3.0 but rather a rework of how certain plugins operated in Core 2.0. Core 2.0 had one major issue that was the result of the late container and plugin system introduction, it was so heavily fragmented to the point where plugins for functionality like loggers existed. You would always be required to include those plugins when bundling Core instead of them being part of a single package that you require in your own packages and have everything ready. required How were services introduced? In Core 3.0 we introduced a new package called which is the amalgamation of various packages that have previously existed in Core 2.0. Examples of those would be , , and more. core-kernel core-container core-logger core-event-emitter The package is the heart of Core 3.0 with the goal of resolving a lot of pain points from previous versions, improve DX, reducing boilerplate for package developers and lastly to reduce the fragmentation that plagues Core 2.0. core-kernel Part of is the directory which comes with a variety of services out of the box to reduce the boilerplate needed for the development of new packages and reduce duplication in existing ones. core-kernel services Actions Cache Config Events Filesystem Log Mixins Queue Schedule Validation We’ll go more in-depth into those services in a later part of this series. Registering your own services Registering your own services is as easy as can be and only takes a few lines of code due to the abstractions that come out of the box for package developers. Lets first have a look at the abstract that comes with Core to reduce the necessary boilerplate for service registrations. ServiceProvider () ServiceProvider { (Identifiers.Application) readonly app: Kernel.Application; packageConfiguration: PackageConfiguration; packageManifest: PackageManifest; register(): < >; boot(): < > { } dispose(): < > { } manifest(): PackageManifest { .packageManifest;
    } setManifest(manifest: PackageManifest): { .packageManifest = manifest;
    } name(): | { ( .packageManifest) { .packageManifest.get( );
        } ;
    } version(): | { ( .packageManifest) { .packageManifest.get( );
        } ;
    } config(): PackageConfiguration { .packageConfiguration;
    } setConfig(config: PackageConfiguration): { .packageConfiguration = config;
    } configDefaults(): JsonObject { {};
    } configSchema(): object { {};
    } dependencies(): Kernel.PackageDependency[] { [];
    } enableWhen(): < > { ;
    } disableWhen(): < > { ;
    } required(): < > { ;
    }
} @injectable export abstract class /**
     * The application instance.
     */ @inject protected /**
     * The application instance.
     */ private /**
     * The loaded manifest.
     */ private /**
     * Register the service provider.
     */ public abstract async Promise void /**
     * Boot the service provider.
     */ public async Promise void // /**
     * Dispose the service provider.
     */ public async Promise void // /**
     * Get the manifest of the service provider.
     */ public return this /**
     * Set the manifest of the service provider.
     */ public void this /**
     * Get the name of the service provider.
     */ public string undefined if this return this "name" return undefined /**
     * Get the version of the service provider.
     *
     * @returns {string}
     * @memberof ServiceProvider
     */ public string undefined if this return this "version" return undefined /**
     * Get the configuration of the service provider.
     */ public return this /**
     * Set the configuration of the service provider.
     */ public void this /**
     * Get the configuration defaults of the service provider.
     */ public return /**
     * Get the configuration schema of the service provider.
     */ public return /**
     * Get the dependencies of the service provider.
     */ public return /**
     * Enable the service provider when the given conditions are met.
     */ public async Promise boolean return true /**
     * Disable the service provider when the given conditions are met.
     */ public async Promise boolean return false /**
     * Determine if the package is required, which influences how bootstrapping errors are handled.
     */ public async Promise boolean return false This is quite a bit of code so let's break it down into digestible parts. The abstract method is called by the bootstrapper classes that are responsible for registering services. This method should only register things, as its name indicates, and not start anything like HTTP servers. register The method is called by the bootstrapper classes that are responsible for booting services. This should act based on what happened in the method, i.e. start an HTTP server. boot register The method is called by the bootstrapper classes that are responsible for disposing of services. This should act based on what happened in the method, i.e. stop an HTTP server. dispose boot The method grants access to the of a package to gather information like name or version. manifest package.json The is called by the bootstrapper classes that are responsible for registering services. The file of a package will be automatically loaded, parsed and finally stored through this method. setManifest package.json The method returns the contents of the name property inside the file of a package. name package.json The method returns the contents of the version property inside the file of a package. version package.json The method grants access to the configuration of a package after it has been validated and normalized. config The method is called by the bootstrapper classes that are responsible for registering services. The configuration will be validated, normalized and finally stored through this method. setConfig The method is called by the bootstrapper classes that are responsible for registering services. The return value of this method will be merged with the user-supplied configuration to ensure all values are available. configDefaults The method is called by the bootstrapper classes that are responsible for registering services. This method has to return a schema that will be used to validate and normalize the configuration. configSchema @hapi/joi The method is called by the bootstrapper classes that are responsible for registering services. The return value of this method has to be an array of objects that contain information like names and version constraints. dependencies The methods are called by the bootstrapper classes when a block is applied and are responsible for (de)registering services. These methods have to return a boolean value that determines when to enable or disable a service. enableWhen / disableWhen The method is called by the bootstrapper classes that are responsible for registering services. This method has to return a boolean value that determines whether or not a service is required. Required plugins receive stricter error handling and any errors during registration or booting result in process termination. required That’s the functionality a service provider comes with out of the box but the only methods you’ll interact with in most cases are and . Let us take a look at an example service provider to illustrate their use. register, boot dispose { Providers } ; { Server } ; ServiceProvider Providers.ServiceProvider { register(): < > { .app.bind<Server>( ).toConstantValue( Server());
    } boot(): < > { .app.get<Server>( ).start();
    } dispose(): < > { .app.get<Server>( ).stop();
    }
} import from "@arkecosystem/core-kernel" import from "@hapi/hapi" export class extends public async Promise void this "api" new public async Promise void await this "api" public async Promise void await this "api" The method binds a new instance of a hapi.js server to the container without starting it. register The method retrieves the previously registered server from the container and calls the start method on it. boot The method retrieves the previously registered server from the container and calls the stop method on it. dispose As you can see it’s pretty easy to register your own services without much hassle and everything is clearly named, let's end with listing some of the benefits of this new architecture compared to Core 2.0. Benefits of new service provider lifecycle Clear separation of responsibilities during application bootstrap.Easy testing due to a clear separation of responsibilities. Ability to enable and disable packages at runtime without a full teardown. The by far biggest benefit for package developers is that it is now possible to alter or extend other packages due to how the application bootstrapping now works. An example of this would be a plugin that adds new routes or plugins to the package before the server is started, all it would take is to resolve the hapi.js server from the container in the method and call the usual methods provided by hapi.js on the resolved value. core-api register This removes the need to spin up your own HTTP server if you just need 1–2 extra API endpoints. Being able to do modify other plugins before they are launched will provide developers with greater control and possibilities to modify how core behaves. What’s next? This concludes Part 3 of the Let's Explore ARK Core series. In the next part, we will delve into how ARK Core 3.0 is more extensible than ever and how you can take advantage of this to reduce your time spent on developing packages. I Want To Help With Development That's great news! If you want to help out, are wide open, but that is not all, we also have special Monthly Development GitHub Bounties on-going where you can earn money for every valid and merged Pull-Request. our GitHub repositories To learn more about the program please read our blog post and to learn more about ARK Core and blockchain visit our . Bounty Program Guidelines Learning Hub

Let's Explore ARK Core: Kernel & Services [Part 3]

The Tara founding team at San Jose HQ Here's a quick debrief of my take on how to set up core values to steer successful company culture at a startup, specifically for teams coming in at a <40 headcount. At Tara AI, we just went through a company core values exercise at our 2020 kick-off. In the last year, we've grown from 4 to 20 folks (!) so, we decided it was high time to set up our values and culture. 1. Values shouldn't be aspirational; rather, they should be a true reflection your team today. To start, everyone in the company (fifteen people at the time) took the time to write a few words to describe the team, and which of our existing values, habits, and behaviours we each admire. Once we mapped the keywords out on post-its, patterns started to emerge. 2. Your Core Values are the habits and mindsets you'll collectively agree to work harder to cultivate than "any other company in the world." Once we had the team's feedback, my co-founder and I started to think about the journey so far, and the values that would enable our company to make a dent in the world. We wanted the core values to be a clear reflection of our goals. One really good example of this is Airbnb: They work harder than anyone on the "Be a Host" core value, which is significant persona for their entire business. Airbnb has carefully developed their company culture around the idea and practice of hosting, which also enables teams to be thoughtful about a "sense of belonging". 3) Core Values will guide your product, your company and your brand. Good core values should outlast the founders. We thought hard about what would we want Tara to embody 5, 10, 20 years from now. 4) Core Values should contribute to and be a key driver of company's success. As we drafted our values, we asked ourselves, if we were to embody these paradigms, habits and behaviours daily, would that lead to significant and sustainable success for the company in the long run? 5) You hire and fire by your company values. We also found it useful to ask "As a team, what are we not, and what do we not do"? A few words and phrases that came up through this exercise were and hierarchical, egotistical, fearing change, vanity metrics, complexity doing things for the sake of doing them. Most companies at early product market fit stage have around 3-4 core values that are easy to remember. These usually evolve to 5 or 7 over time. Through this exercise, we came up with four: 1. Team-First Mindset Not only internally, but also externally: we build software to help product teams. We prioritize those teams and their experiences with our platform. The team is seen as the most important decision-making unit in the company (whether internal or external). 2. Ambitious, Never Arrogant We continue to push boundaries while remaining humble and true to our mission. We do not rest on our laurels. 3. Real Value Over Perceived Value, Every Time We build real value for our users and for ourselves. We continue to ask ourselves if we're building what teams truly want. 4. Artisans In Everything We Do Care and craftsmanship in our work. We are thoughtful with design in every pixel, and we ship production code with quality over quantity. Did you spot the acronym? That's right, our correlate to our name: TARA. This makes them easy to remember, and enables our organization to see how embodying these values is now, quite literally, baked into our name. Now for the real challenge: Operationalizing these core values, and truly embodying them in our day-to-day activities. To start, we announced our core values at our 2020 kick-off, and since then we've also added them to our "welcome pack" for on-boarding new team members. As a team, we are now working through internalizing these core values. It will be interesting to see how we start to rely on our values as a decision-making matrix, and continue to evaluate how we embody these values as we grow. I'll keep you updated...

5 Prompts to Help You Define Core Values at Your Early-Stage Startup

What Are the Top Startups in Oceania?

The race for the next decentralized social network has officially begun, following this tweet from Twitter CEO, Jack Dorsey. There are two fundamental issues with existing social networks. 1. Brain hacking. Platforms have shown capabilities of manipulating and deceiving people, through fake news, the spread of misinformation and echo chambers. 2. Censorship. Governments all around the world censor social networks when they feel threatened; thus suppressing people’s right to access information. The main benefit of a decentralized social networking architecture would be it could be a solution to both of the problems mentioned above. There have been many attempts to create open social networks. From a technical standpoint, they may be categorized as follows: Distributed Data (DD) Distributed Identities (DI) Distributed Communities (DC) 1. Distributed Data (DD) In the distributed data model, all user-generated-content (including multimedia assets as well as database records) are stored: (a) in a verifiable ledger such as Ethereum or Blockstack. (b) peer-to-peer via distributed gossip protocols such as secure-scuttlebut ( ) https://ssbc.github.io/scuttlebutt-protocol-guide/ 1a. Verifiable Ledger This approach comes with the clear disadvantage of crypto-verification overhead and paying transaction fees for each insert or update operation. Blockchains are known to be highly inefficient data stores. They are usable only with handful of applications where the benefits outweigh the drawbacks; unfortunately, social networking is not one of them. As a consequence, many early attempts like Leeroy have already shut down, and there are only a small number of them like Peepeth, which still exist but continue to fizzle. Besides, with the DD approach, consumers are required to install an additional browser plug-in to use the services. While MetaMask, in the form of a Chrome extension, is the most user-friendly one, the time has proven, on multiple occasions, that extra friction, no matter how little it is, never goes welcome with the consumers. 1b. Peer to Peer Crypto is not the only backend adapter for the distributed data model. There is ongoing research in creating distributed data social networks · Completely among the client’s browsers [see gun.eco] peer-to-peer · Through such as Dropbox and Google Drive, [see ] public cloud services POSN but both are far from becoming applicable. One can develop a peer-to-peer social network without the limitations of the browser, using a distributed gossip protocol such as on a desktop or mobile app similar to Patchwork, Planetary. secure-scuttlebutt A big disadvantage with this approach is that the nicknames (to identify the user) cannot be unique since there is no global registry, and the only solution is to rely on centralized services. Last but not least, the Reddit-like desktop app Aether follows a similar approach but with an ephemeral append-only log (DAG) to store data, rather than relying on ssb. 2. Distributed Identities (DI) There are several federated protocols, led by Microformats and Indieweb communities that suggest personal websites to represent one’s online digital identity. Accordingly, such sites interact with each other via open pub/sub-protocols such. Even W3C has specific recommendations that date back to 2017 like WebMention ( ) https://www.w3.org/TR/webmention/ IndieWeb oversees online activities to be aggregated in open-source silos. For example, micro.blog is one such aggregator that can interact with people’s websites via WebMentions. These small groups of like-minded “distributed identities” advocates gather online and offline sporadically, but they have failed to gain mainstream attention, due to: - The lack of consistent user-interface - of these technologies and launching such personal websites. Difficulty in the adoption - at the aggregator (newsfeed) level Inefficiencies Although, the distributed identity approach has no or negligible performance drawbacks as opposed to the DD, with a minor exception of the “aggregator” level. On a positive note, they are philosophically similar to SMTP and POP3, which constitute the email communications infrastructure. 3. Distributed Communities (DC) Perhaps the most realistic one among all three approaches is the “Distributed Communities” one, where the social network is not one giant graph (a la Facebook or Twitter) but constitutes of many subgraphs around shared topics. Ning and Grou.ps are two such early, yet central examples. On the other hand, the new open-source upcomers such as Mastodon, GNU Social and DiSo do the same, taking a somewhat more decentralized approach where community owners host the open-source software on their own, and there’s an underlying open federated protocol (ActivityPub) that connects the subgraphs. The main benefit of the DC approach is the fact that, besides technical decentralization, more abstract (yet important) aspects of the network such as governance, moderation, and value-creation, are also split between multiple parties. This is a positive direction, because otherwise, in a giant decentralized network, it will prove much harder to own, regulate, and moderate than one might estimate. The disadvantage of current DC based software is, while they borrow some ideas from the DI approach, with WebMention allowing Mastodon cross-follows across the networks, they are far from being usable and useful, mainly because the identities are completely isolated from each other. To illustrate it on Mastodon, (with the email ) has nothing in common with the same user on a different network, say with the same email esokullu@gmail.com. esokullu@mastodon.social esokullu@gmail.com esokullu@php-enthusiasts.social Additionally, the architecture they’re built with, which is based on traditional MVC and relational databases, makes them impossible to scale out in a way regular people or software developers can. Last but not least, with their shared-nothing data model, Mastodon and the likes have no answer to the censorship problem. How is Phở Networks different? is essentially a programming language, rather than a social network. But it lets people build decentralized social applications. Hence, it’s more comparable to secure-scuttlebutt rather than the social networking platforms discussed above. Phở Networks Phở does not attempt to recreate a whole new web with the client-to-client model replacing the traditional server-client one. It’s rather an attempt to create a camaraderie-network between servers. Accordingly, the decentralized apps created on Phở communicate with each other and reroute queries when one is blocked. This is in order to solve the problem that also touched me personally in 2014. censorship Phở uses the Kademlia principles to achieve its goals. Kademlia was also used in Gnutella, and IPFS. For more information, you may take a . look at the paper here Last but not least, Phở comes with an open-source application called , which lets people build their own online communities in line with the DC (Distributed Communities) approach, hence it is a completely a decentralized social networking stack as it satisfies both the DC –with manageable moderation/regulation– and DD (Distributed Data) –with censorship-resistance– principles. Groupsville

Stories, News & Mentions about UPCORE

Upcore’s Stories on HackerNoon