@ eac63075:b4988b48

Based on a recent paper that included collaboration from renowned experts such as Lynn Alden, Steve Lee, and Ren Crypto Fish, we discuss in depth how Bitcoin's consensus is built, the main risks, and the complex dynamics of protocol upgrades.

PT-BR version

Podcast https://www.fountain.fm/episode/wbjD6ntQuvX5u2G5BccC

Presentation https://gamma.app/docs/Analyzing-Bitcoin-Consensus-Risks-in-Protocol-Upgrades-p66axxjwaa37ksn

1. Introduction to Consensus in Bitcoin

Consensus in Bitcoin is the foundation that keeps the network secure and functional, allowing users worldwide to perform transactions in a decentralized manner without the need for intermediaries. Since its launch in 2009, Bitcoin is often described as an "immutable" system designed to resist changes, and it is precisely this resistance that ensures its security and stability.

The central idea behind consensus in Bitcoin is to create a set of acceptance rules for blocks and transactions, ensuring that all network participants agree on the transaction history. This prevents "double-spending," where the same bitcoin could be used in two simultaneous transactions, something that would compromise trust in the network.

Evolution of Consensus in Bitcoin

Over the years, consensus in Bitcoin has undergone several adaptations, and the way participants agree on changes remains a delicate process. Unlike traditional systems, where changes can be imposed from the top down, Bitcoin operates in a decentralized model where any significant change needs the support of various groups of stakeholders, including miners, developers, users, and large node operators.

Moreover, the update process is extremely cautious, as hasty changes can compromise the network's security. As a result, the philosophy of "don't fix what isn't broken" prevails, with improvements happening incrementally and only after broad consensus among those involved. This model can make progress seem slow but ensures that Bitcoin remains faithful to the principles of security and decentralization.

---

2. Technical Components of Consensus

Bitcoin's consensus is supported by a set of technical rules that determine what is considered a valid transaction and a valid block on the network. These technical aspects ensure that all nodes—the computers that participate in the Bitcoin network—agree on the current state of the blockchain. Below are the main technical components that form the basis of the consensus.

Validation of Blocks and Transactions

The validation of blocks and transactions is the central point of consensus in Bitcoin. A block is only considered valid if it meets certain criteria, such as maximum size, transaction structure, and the solving of the "Proof of Work" problem. The proof of work, required for a block to be included in the blockchain, is a computational process that ensures the block contains significant computational effort—protecting the network against manipulation attempts.

Transactions, in turn, need to follow specific input and output rules. Each transaction includes cryptographic signatures that prove the ownership of the bitcoins sent, as well as validation scripts that verify if the transaction conditions are met. This validation system is essential for network nodes to autonomously confirm that each transaction follows the rules.

Chain Selection

Another fundamental technical issue for Bitcoin's consensus is chain selection, which becomes especially important in cases where multiple versions of the blockchain coexist, such as after a network split (fork). To decide which chain is the "true" one and should be followed, the network adopts the criterion of the highest accumulated proof of work. In other words, the chain with the highest number of valid blocks, built with the greatest computational effort, is chosen by the network as the official one.

This criterion avoids permanent splits because it encourages all nodes to follow the same main chain, reinforcing consensus.

Soft Forks vs. Hard Forks

In the consensus process, protocol changes can happen in two ways: through soft forks or hard forks. These variations affect not only the protocol update but also the implications for network users:

• Soft Forks: These are changes that are backward compatible. Only nodes that adopt the new update will follow the new rules, but old nodes will still recognize the blocks produced with these rules as valid. This compatibility makes soft forks a safer option for updates, as it minimizes the risk of network division.

• Hard Forks: These are updates that are not backward compatible, requiring all nodes to update to the new version or risk being separated from the main chain. Hard forks can result in the creation of a new coin, as occurred with the split between Bitcoin and Bitcoin Cash in 2017. While hard forks allow for deeper changes, they also bring significant risks of network fragmentation.

These technical components form the base of Bitcoin's security and resilience, allowing the system to remain functional and immutable without losing the necessary flexibility to evolve over time.

---

3. Stakeholders in Bitcoin's Consensus

Consensus in Bitcoin is not decided centrally. On the contrary, it depends on the interaction between different groups of stakeholders, each with their motivations, interests, and levels of influence. These groups play fundamental roles in how changes are implemented or rejected on the network. Below, we explore the six main stakeholders in Bitcoin's consensus.

1. Economic Nodes

Economic nodes, usually operated by exchanges, custody providers, and large companies that accept Bitcoin, exert significant influence over consensus. Because they handle large volumes of transactions and act as a connection point between the Bitcoin ecosystem and the traditional financial system, these nodes have the power to validate or reject blocks and to define which version of the software to follow in case of a fork.

Their influence is proportional to the volume of transactions they handle, and they can directly affect which chain will be seen as the main one. Their incentive is to maintain the network's stability and security to preserve its functionality and meet regulatory requirements.

2. Investors

Investors, including large institutional funds and individual Bitcoin holders, influence consensus indirectly through their impact on the asset's price. Their buying and selling actions can affect Bitcoin's value, which in turn influences the motivation of miners and other stakeholders to continue investing in the network's security and development.

Some institutional investors have agreements with custodians that may limit their ability to act in network split situations. Thus, the impact of each investor on consensus can vary based on their ownership structure and how quickly they can react to a network change.

3. Media Influencers

Media influencers, including journalists, analysts, and popular personalities on social media, have a powerful role in shaping public opinion about Bitcoin and possible updates. These influencers can help educate the public, promote debates, and bring transparency to the consensus process.

On the other hand, the impact of influencers can be double-edged: while they can clarify complex topics, they can also distort perceptions by amplifying or minimizing change proposals. This makes them a force both of support and resistance to consensus.

4. Miners

Miners are responsible for validating transactions and including blocks in the blockchain. Through computational power (hashrate), they also exert significant influence over consensus decisions. In update processes, miners often signal their support for a proposal, indicating that the new version is safe to use. However, this signaling is not always definitive, and miners can change their position if they deem it necessary.

Their incentive is to maximize returns from block rewards and transaction fees, as well as to maintain the value of investments in their specialized equipment, which are only profitable if the network remains stable.

5. Protocol Developers

Protocol developers, often called "Core Developers," are responsible for writing and maintaining Bitcoin's code. Although they do not have direct power over consensus, they possess an informal veto power since they decide which changes are included in the main client (Bitcoin Core). This group also serves as an important source of technical knowledge, helping guide decisions and inform other stakeholders.

Their incentive lies in the continuous improvement of the network, ensuring security and decentralization. Many developers are funded by grants and sponsorships, but their motivations generally include a strong ideological commitment to Bitcoin's principles.

6. Users and Application Developers

This group includes people who use Bitcoin in their daily transactions and developers who build solutions based on the network, such as wallets, exchanges, and payment platforms. Although their power in consensus is less than that of miners or economic nodes, they play an important role because they are responsible for popularizing Bitcoin's use and expanding the ecosystem.

If application developers decide not to adopt an update, this can affect compatibility and widespread acceptance. Thus, they indirectly influence consensus by deciding which version of the protocol to follow in their applications.

These stakeholders are vital to the consensus process, and each group exerts influence according to their involvement, incentives, and ability to act in situations of change. Understanding the role of each makes it clearer how consensus is formed and why it is so difficult to make significant changes to Bitcoin.

---

4. Mechanisms for Activating Updates in Bitcoin

For Bitcoin to evolve without compromising security and consensus, different mechanisms for activating updates have been developed over the years. These mechanisms help coordinate changes among network nodes to minimize the risk of fragmentation and ensure that updates are implemented in an orderly manner. Here, we explore some of the main methods used in Bitcoin, their advantages and disadvantages, as well as historical examples of significant updates.

Flag Day

The Flag Day mechanism is one of the simplest forms of activating changes. In it, a specific date or block is determined as the activation moment, and all nodes must be updated by that point. This method does not involve prior signaling; participants simply need to update to the new software version by the established day or block.

• Advantages: Simplicity and predictability are the main benefits of Flag Day, as everyone knows the exact activation date.

• Disadvantages: Inflexibility can be a problem because there is no way to adjust the schedule if a significant part of the network has not updated. This can result in network splits if a significant number of nodes are not ready for the update.

An example of Flag Day was the Pay to Script Hash (P2SH) update in 2012, which required all nodes to adopt the change to avoid compatibility issues.

BIP34 and BIP9

BIP34 introduced a more dynamic process, in which miners increase the version number in block headers to signal the update. When a predetermined percentage of the last blocks is mined with this new version, the update is automatically activated. This model later evolved with BIP9, which allowed multiple updates to be signaled simultaneously through "version bits," each corresponding to a specific change.

• Advantages: Allows the network to activate updates gradually, giving more time for participants to adapt.

• Disadvantages: These methods rely heavily on miner support, which means that if a sufficient number of miners do not signal the update, it can be delayed or not implemented.

BIP9 was used in the activation of SegWit (BIP141) but faced challenges because some miners did not signal their intent to activate, leading to the development of new mechanisms.

User Activated Soft Forks (UASF) and User Resisted Soft Forks (URSF)

To increase the decision-making power of ordinary users, the concept of User Activated Soft Fork (UASF) was introduced, allowing node operators, not just miners, to determine consensus for a change. In this model, nodes set a date to start rejecting blocks that are not in compliance with the new update, forcing miners to adapt or risk having their blocks rejected by the network.

URSF, in turn, is a model where nodes reject blocks that attempt to adopt a specific update, functioning as resistance against proposed changes.

• Advantages: UASF returns decision-making power to node operators, ensuring that changes do not depend solely on miners.

• Disadvantages: Both UASF and URSF can generate network splits, especially in cases of strong opposition among different stakeholders.

An example of UASF was the activation of SegWit in 2017, where users supported activation independently of miner signaling, which ended up forcing its adoption.

BIP8 (LOT=True)

BIP8 is an evolution of BIP9, designed to prevent miners from indefinitely blocking a change desired by the majority of users and developers. BIP8 allows setting a parameter called "lockinontimeout" (LOT) as true, which means that if the update has not been fully signaled by a certain point, it is automatically activated.

• Advantages: Ensures that changes with broad support among users are not blocked by miners who wish to maintain the status quo.

• Disadvantages: Can lead to network splits if miners or other important stakeholders do not support the update.

Although BIP8 with LOT=True has not yet been used in Bitcoin, it is a proposal that can be applied in future updates if necessary.

These activation mechanisms have been essential for Bitcoin's development, allowing updates that keep the network secure and functional. Each method brings its own advantages and challenges, but all share the goal of preserving consensus and network cohesion.

---

5. Risks and Considerations in Consensus Updates

Consensus updates in Bitcoin are complex processes that involve not only technical aspects but also political, economic, and social considerations. Due to the network's decentralized nature, each change brings with it a set of risks that need to be carefully assessed. Below, we explore some of the main challenges and future scenarios, as well as the possible impacts on stakeholders.

Network Fragility with Alternative Implementations

One of the main risks associated with consensus updates is the possibility of network fragmentation when there are alternative software implementations. If an update is implemented by a significant group of nodes but rejected by others, a network split (fork) can occur. This creates two competing chains, each with a different version of the transaction history, leading to unpredictable consequences for users and investors.

Such fragmentation weakens Bitcoin because, by dividing hashing power (computing) and coin value, it reduces network security and investor confidence. A notable example of this risk was the fork that gave rise to Bitcoin Cash in 2017 when disagreements over block size resulted in a new chain and a new asset.

Chain Splits and Impact on Stakeholders

Chain splits are a significant risk in update processes, especially in hard forks. During a hard fork, the network is split into two separate chains, each with its own set of rules. This results in the creation of a new coin and leaves users with duplicated assets on both chains. While this may seem advantageous, in the long run, these splits weaken the network and create uncertainties for investors.

Each group of stakeholders reacts differently to a chain split:

• Institutional Investors and ETFs: Face regulatory and compliance challenges because many of these assets are managed under strict regulations. The creation of a new coin requires decisions to be made quickly to avoid potential losses, which may be hampered by regulatory constraints.

• Miners: May be incentivized to shift their computing power to the chain that offers higher profitability, which can weaken one of the networks.

• Economic Nodes: Such as major exchanges and custody providers, have to quickly choose which chain to support, influencing the perceived value of each network.

Such divisions can generate uncertainties and loss of value, especially for institutional investors and those who use Bitcoin as a store of value.

Regulatory Impacts and Institutional Investors

With the growing presence of institutional investors in Bitcoin, consensus changes face new compliance challenges. Bitcoin ETFs, for example, are required to follow strict rules about which assets they can include and how chain split events should be handled. The creation of a new asset or migration to a new chain can complicate these processes, creating pressure for large financial players to quickly choose a chain, affecting the stability of consensus.

Moreover, decisions regarding forks can influence the Bitcoin futures and derivatives market, affecting perception and adoption by new investors. Therefore, the need to avoid splits and maintain cohesion is crucial to attract and preserve the confidence of these investors.

Security Considerations in Soft Forks and Hard Forks

While soft forks are generally preferred in Bitcoin for their backward compatibility, they are not without risks. Soft forks can create different classes of nodes on the network (updated and non-updated), which increases operational complexity and can ultimately weaken consensus cohesion. In a network scenario with fragmentation of node classes, Bitcoin's security can be affected, as some nodes may lose part of the visibility over updated transactions or rules.

In hard forks, the security risk is even more evident because all nodes need to adopt the new update to avoid network division. Experience shows that abrupt changes can create temporary vulnerabilities, in which malicious agents try to exploit the transition to attack the network.

Bounty Claim Risks and Attack Scenarios

Another risk in consensus updates are so-called "bounty claims"—accumulated rewards that can be obtained if an attacker manages to split or deceive a part of the network. In a conflict scenario, a group of miners or nodes could be incentivized to support a new update or create an alternative version of the software to benefit from these rewards.

These risks require stakeholders to carefully assess each update and the potential vulnerabilities it may introduce. The possibility of "bounty claims" adds a layer of complexity to consensus because each interest group may see a financial opportunity in a change that, in the long term, may harm network stability.

The risks discussed above show the complexity of consensus in Bitcoin and the importance of approaching it gradually and deliberately. Updates need to consider not only technical aspects but also economic and social implications, in order to preserve Bitcoin's integrity and maintain trust among stakeholders.

---

6. Recommendations for the Consensus Process in Bitcoin

To ensure that protocol changes in Bitcoin are implemented safely and with broad support, it is essential that all stakeholders adopt a careful and coordinated approach. Here are strategic recommendations for evaluating, supporting, or rejecting consensus updates, considering the risks and challenges discussed earlier, along with best practices for successful implementation.

1. Careful Evaluation of Proposal Maturity

Stakeholders should rigorously assess the maturity level of a proposal before supporting its implementation. Updates that are still experimental or lack a robust technical foundation can expose the network to unnecessary risks. Ideally, change proposals should go through an extensive testing phase, have security audits, and receive review and feedback from various developers and experts.

2. Extensive Testing in Secure and Compatible Networks

Before an update is activated on the mainnet, it is essential to test it on networks like testnet and signet, and whenever possible, on other compatible networks that offer a safe and controlled environment to identify potential issues. Testing on networks like Litecoin was fundamental for the safe launch of innovations like SegWit and the Lightning Network, allowing functionalities to be validated on a lower-impact network before being implemented on Bitcoin.

The Liquid Network, developed by Blockstream, also plays an important role as an experimental network for new proposals, such as OP_CAT. By adopting these testing environments, stakeholders can mitigate risks and ensure that the update is reliable and secure before being adopted by the main network.

3. Importance of Stakeholder Engagement

The success of a consensus update strongly depends on the active participation of all stakeholders. This includes economic nodes, miners, protocol developers, investors, and end users. Lack of participation can lead to inadequate decisions or even future network splits, which would compromise Bitcoin's security and stability.

4. Key Questions for Evaluating Consensus Proposals

To assist in decision-making, each group of stakeholders should consider some key questions before supporting a consensus change:

• Does the proposal offer tangible benefits for Bitcoin's security, scalability, or usability?
• Does it maintain backward compatibility or introduce the risk of network split?
• Are the implementation requirements clear and feasible for each group involved?
• Are there clear and aligned incentives for all stakeholder groups to accept the change?

5. Coordination and Timing in Implementations

Timing is crucial. Updates with short activation windows can force a split because not all nodes and miners can update simultaneously. Changes should be planned with ample deadlines to allow all stakeholders to adjust their systems, avoiding surprises that could lead to fragmentation.

Mechanisms like soft forks are generally preferable to hard forks because they allow a smoother transition. Opting for backward-compatible updates when possible facilitates the process and ensures that nodes and miners can adapt without pressure.

6. Continuous Monitoring and Re-evaluation

After an update, it's essential to monitor the network to identify problems or side effects. This continuous process helps ensure cohesion and trust among all participants, keeping Bitcoin as a secure and robust network.

These recommendations, including the use of secure networks for extensive testing, promote a collaborative and secure environment for Bitcoin's consensus process. By adopting a deliberate and strategic approach, stakeholders can preserve Bitcoin's value as a decentralized and censorship-resistant network.

---

7. Conclusion

Consensus in Bitcoin is more than a set of rules; it's the foundation that sustains the network as a decentralized, secure, and reliable system. Unlike centralized systems, where decisions can be made quickly, Bitcoin requires a much more deliberate and cooperative approach, where the interests of miners, economic nodes, developers, investors, and users must be considered and harmonized. This governance model may seem slow, but it is fundamental to preserving the resilience and trust that make Bitcoin a global store of value and censorship-resistant.

Consensus updates in Bitcoin must balance the need for innovation with the preservation of the network's core principles. The development process of a proposal needs to be detailed and rigorous, going through several testing stages, such as in testnet, signet, and compatible networks like Litecoin and Liquid Network. These networks offer safe environments for proposals to be analyzed and improved before being launched on the main network.

Each proposed change must be carefully evaluated regarding its maturity, impact, backward compatibility, and support among stakeholders. The recommended key questions and appropriate timing are critical to ensure that an update is adopted without compromising network cohesion. It's also essential that the implementation process is continuously monitored and re-evaluated, allowing adjustments as necessary and minimizing the risk of instability.

By following these guidelines, Bitcoin's stakeholders can ensure that the network continues to evolve safely and robustly, maintaining user trust and further solidifying its role as one of the most resilient and innovative digital assets in the world. Ultimately, consensus in Bitcoin is not just a technical issue but a reflection of its community and the values it represents: security, decentralization, and resilience.

---

8. Links

Whitepaper: https://github.com/bitcoin-cap/bcap

Youtube (pt-br): https://www.youtube.com/watch?v=rARycAibl9o&list=PL-qnhF0qlSPkfhorqsREuIu4UTbF0h4zb

@ eac63075:b4988b48

The future of physical money is at stake, and the discussion about DREX, the new digital currency planned by the Central Bank of Brazil, is gaining momentum. In a candid and intense conversation, Federal Deputy Julia Zanatta (PL/SC) discussed the challenges and risks of this digital transition, also addressing her Bill No. 3,341/2024, which aims to prevent the extinction of physical currency. This bill emerges as a direct response to legislative initiatives seeking to replace physical money with digital alternatives, limiting citizens' options and potentially compromising individual freedom. Let's delve into the main points of this conversation.

https://www.fountain.fm/episode/i5YGJ9Ors3PkqAIMvNQ0

(PT-BR version here)

What is a CBDC?

Before discussing the specifics of DREX, it’s important to understand what a CBDC (Central Bank Digital Currency) is. CBDCs are digital currencies issued by central banks, similar to a digital version of physical money. Unlike cryptocurrencies such as Bitcoin, which operate in a decentralized manner, CBDCs are centralized and regulated by the government. In other words, they are digital currencies created and controlled by the Central Bank, intended to replace physical currency.

A prominent feature of CBDCs is their programmability. This means that the government can theoretically set rules about how, where, and for what this currency can be used. This aspect enables a level of control over citizens' finances that is impossible with physical money. By programming the currency, the government could limit transactions by setting geographical or usage restrictions. In practice, money within a CBDC could be restricted to specific spending or authorized for use in a defined geographical area.

In countries like China, where citizen actions and attitudes are also monitored, a person considered to have a "low score" due to a moral or ideological violation may have their transactions limited to essential purchases, restricting their digital currency use to non-essential activities. This financial control is strengthened because, unlike physical money, digital currency cannot be exchanged anonymously.

Practical Example: The Case of DREX During the Pandemic

To illustrate how DREX could be used, an example was given by Eric Altafim, director of Banco Itaú. He suggested that, if DREX had existed during the COVID-19 pandemic, the government could have restricted the currency’s use to a 5-kilometer radius around a person’s residence, limiting their economic mobility. Another proposed use by the executive related to the Bolsa Família welfare program: the government could set up programming that only allows this benefit to be used exclusively for food purchases. Although these examples are presented as control measures for safety or organization, they demonstrate how much a CBDC could restrict citizens' freedom of choice.

To illustrate the potential for state control through a Central Bank Digital Currency (CBDC), such as DREX, it is helpful to look at the example of China. In China, the implementation of a CBDC coincides with the country’s Social Credit System, a governmental surveillance tool that assesses citizens' and companies' behavior. Together, these technologies allow the Chinese government to monitor, reward, and, above all, punish behavior deemed inappropriate or threatening to the government.

How Does China's Social Credit System Work?

Implemented in 2014, China's Social Credit System assigns every citizen and company a "score" based on various factors, including financial behavior, criminal record, social interactions, and even online activities. This score determines the benefits or penalties each individual receives and can affect everything from public transport access to obtaining loans and enrolling in elite schools for their children. Citizens with low scores may face various sanctions, including travel restrictions, fines, and difficulty in securing loans.

With the adoption of the CBDC — or “digital yuan” — the Chinese government now has a new tool to closely monitor citizens' financial transactions, facilitating the application of Social Credit System penalties. China’s CBDC is a programmable digital currency, which means that the government can restrict how, when, and where the money can be spent. Through this level of control, digital currency becomes a powerful mechanism for influencing citizens' behavior.

Imagine, for instance, a citizen who repeatedly posts critical remarks about the government on social media or participates in protests. If the Social Credit System assigns this citizen a low score, the Chinese government could, through the CBDC, restrict their money usage in certain areas or sectors. For example, they could be prevented from buying tickets to travel to other regions, prohibited from purchasing certain consumer goods, or even restricted to making transactions only at stores near their home.

Another example of how the government can use the CBDC to enforce the Social Credit System is by monitoring purchases of products such as alcohol or luxury items. If a citizen uses the CBDC to spend more than the government deems reasonable on such products, this could negatively impact their social score, resulting in additional penalties such as future purchase restrictions or a lowered rating that impacts their personal and professional lives.

In China, this kind of control has already been demonstrated in several cases. Citizens added to Social Credit System “blacklists” have seen their spending and investment capacity severely limited. The combination of digital currency and social scores thus creates a sophisticated and invasive surveillance system, through which the Chinese government controls important aspects of citizens’ financial lives and individual freedoms.

Deputy Julia Zanatta views these examples with great concern. She argues that if the state has full control over digital money, citizens will be exposed to a level of economic control and surveillance never seen before. In a democracy, this control poses a risk, but in an authoritarian regime, it could be used as a powerful tool of repression.

DREX and Bill No. 3,341/2024

Julia Zanatta became aware of a bill by a Workers' Party (PT) deputy (Bill 4068/2020 by Deputy Reginaldo Lopes - PT/MG) that proposes the extinction of physical money within five years, aiming for a complete transition to DREX, the digital currency developed by the Central Bank of Brazil. Concerned about the impact of this measure, Julia drafted her bill, PL No. 3,341/2024, which prohibits the elimination of physical money, ensuring citizens the right to choose physical currency.

“The more I read about DREX, the less I want its implementation,” says the deputy. DREX is a Central Bank Digital Currency (CBDC), similar to other state digital currencies worldwide, but which, according to Julia, carries extreme control risks. She points out that with DREX, the State could closely monitor each citizen’s transactions, eliminating anonymity and potentially restricting freedom of choice. This control would lie in the hands of the Central Bank, which could, in a crisis or government change, “freeze balances or even delete funds directly from user accounts.”

Risks and Individual Freedom

Julia raises concerns about potential abuses of power that complete digitalization could allow. In a democracy, state control over personal finances raises serious questions, and EddieOz warns of an even more problematic future. “Today we are in a democracy, but tomorrow, with a government transition, we don't know if this kind of power will be used properly or abused,” he states. In other words, DREX gives the State the ability to restrict or condition the use of money, opening the door to unprecedented financial surveillance.

EddieOz cites Nigeria as an example, where a CBDC was implemented, and the government imposed severe restrictions on the use of physical money to encourage the use of digital currency, leading to protests and clashes in the country. In practice, the poorest and unbanked — those without regular access to banking services — were harshly affected, as without physical money, many cannot conduct basic transactions. Julia highlights that in Brazil, this situation would be even more severe, given the large number of unbanked individuals and the extent of rural areas where access to technology is limited.

The Relationship Between DREX and Pix

The digital transition has already begun with Pix, which revolutionized instant transfers and payments in Brazil. However, Julia points out that Pix, though popular, is a citizen’s choice, while DREX tends to eliminate that choice. The deputy expresses concern about new rules suggested for Pix, such as daily transaction limits of a thousand reais, justified as anti-fraud measures but which, in her view, represent additional control and a profit opportunity for banks. “How many more rules will banks create to profit from us?” asks Julia, noting that DREX could further enhance control over personal finances.

International Precedents and Resistance to CBDC

The deputy also cites examples from other countries resisting the idea of a centralized digital currency. In the United States, states like New Hampshire have passed laws to prevent the advance of CBDCs, and leaders such as Donald Trump have opposed creating a national digital currency. Trump, addressing the topic, uses a justification similar to Julia’s: in a digitalized system, “with one click, your money could disappear.” She agrees with the warning, emphasizing the control risk that a CBDC represents, especially for countries with disadvantaged populations.

Besides the United States, Canada, Colombia, and Australia have also suspended studies on digital currencies, citing the need for further discussions on population impacts. However, in Brazil, the debate on DREX is still limited, with few parliamentarians and political leaders openly discussing the topic. According to Julia, only she and one or two deputies are truly trying to bring this discussion to the Chamber, making DREX’s advance even more concerning.

Bill No. 3,341/2024 and Popular Pressure

For Julia, her bill is a first step. Although she acknowledges that ideally, it would prevent DREX's implementation entirely, PL 3341/2024 is a measure to ensure citizens' choice to use physical money, preserving a form of individual freedom. “If the future means control, I prefer to live in the past,” Julia asserts, reinforcing that the fight for freedom is at the heart of her bill.

However, the deputy emphasizes that none of this will be possible without popular mobilization. According to her, popular pressure is crucial for other deputies to take notice and support PL 3341. “I am only one deputy, and we need the public’s support to raise the project’s visibility,” she explains, encouraging the public to press other parliamentarians and ask them to “pay attention to PL 3341 and the project that prohibits the end of physical money.” The deputy believes that with a strong awareness and pressure movement, it is possible to advance the debate and ensure Brazilians’ financial freedom.

What’s at Stake?

Julia Zanatta leaves no doubt: DREX represents a profound shift in how money will be used and controlled in Brazil. More than a simple modernization of the financial system, the Central Bank’s CBDC sets precedents for an unprecedented level of citizen surveillance and control in the country. For the deputy, this transition needs to be debated broadly and transparently, and it’s up to the Brazilian people to defend their rights and demand that the National Congress discuss these changes responsibly.

The deputy also emphasizes that, regardless of political or partisan views, this issue affects all Brazilians. “This agenda is something that will affect everyone. We need to be united to ensure people understand the gravity of what could happen.” Julia believes that by sharing information and generating open debate, it is possible to prevent Brazil from following the path of countries that have already implemented a digital currency in an authoritarian way.

A Call to Action

The future of physical money in Brazil is at risk. For those who share Deputy Julia Zanatta’s concerns, the time to act is now. Mobilize, get informed, and press your representatives. PL 3341/2024 is an opportunity to ensure that Brazilian citizens have a choice in how to use their money, without excessive state interference or surveillance.

In the end, as the deputy puts it, the central issue is freedom. “My fear is that this project will pass, and people won’t even understand what is happening.” Therefore, may every citizen at least have the chance to understand what’s at stake and make their voice heard in defense of a Brazil where individual freedom and privacy are respected values.

@ eac63075:b4988b48

Imagine sending a private message to a friend, only to learn that authorities could be scanning its contents without your knowledge. This isn't a scene from a dystopian novel but a potential reality under the European Union's proposed "Chat Control" measures. Aimed at combating serious crimes like child exploitation and terrorism, these proposals could significantly impact the privacy of everyday internet users. As encrypted messaging services become the norm for personal and professional communication, understanding Chat Control is essential. This article delves into what Chat Control entails, why it's being considered, and how it could affect your right to private communication.

https://www.fountain.fm/episode/coOFsst7r7mO1EP1kSzV

https://open.spotify.com/episode/0IZ6kMExfxFm4FHg5DAWT8?si=e139033865e045de

Sections:

• Introduction
• What Is Chat Control?
• Why Is the EU Pushing for Chat Control?
• The Privacy Concerns and Risks
• The Technical Debate: Encryption and Backdoors
• Global Reactions and the Debate in Europe
• Possible Consequences for Messaging Services
• What Happens Next? The Future of Chat Control
• Conclusion

---

What Is Chat Control?

"Chat Control" refers to a set of proposed measures by the European Union aimed at monitoring and scanning private communications on messaging platforms. The primary goal is to detect and prevent the spread of illegal content, such as child sexual abuse material (CSAM) and to combat terrorism. While the intention is to enhance security and protect vulnerable populations, these proposals have raised significant privacy concerns.

At its core, Chat Control would require messaging services to implement automated scanning technologies that can analyze the content of messages—even those that are end-to-end encrypted. This means that the private messages you send to friends, family, or colleagues could be subject to inspection by algorithms designed to detect prohibited content.

Origins of the Proposal

The initiative for Chat Control emerged from the EU's desire to strengthen its digital security infrastructure. High-profile cases of online abuse and the use of encrypted platforms by criminal organizations have prompted lawmakers to consider more invasive surveillance tactics. The European Commission has been exploring legislation that would make it mandatory for service providers to monitor communications on their platforms.

How Messaging Services Work

Most modern messaging apps, like Signal, Session, SimpleX, Veilid, Protonmail and Tutanota (among others), use end-to-end encryption (E2EE). This encryption ensures that only the sender and the recipient can read the messages being exchanged. Not even the service providers can access the content. This level of security is crucial for maintaining privacy in digital communications, protecting users from hackers, identity thieves, and other malicious actors.

Key Elements of Chat Control

• Automated Content Scanning: Service providers would use algorithms to scan messages for illegal content.
• Circumvention of Encryption: To scan encrypted messages, providers might need to alter their encryption methods, potentially weakening security.
• Mandatory Reporting: If illegal content is detected, providers would be required to report it to authorities.
• Broad Applicability: The measures could apply to all messaging services operating within the EU, affecting both European companies and international platforms.

Why It Matters

Understanding Chat Control is essential because it represents a significant shift in how digital privacy is handled. While combating illegal activities online is crucial, the methods proposed could set a precedent for mass surveillance and the erosion of privacy rights. Everyday users who rely on encrypted messaging for personal and professional communication might find their conversations are no longer as private as they once thought.

---

Why Is the EU Pushing for Chat Control?

The European Union's push for Chat Control stems from a pressing concern to protect its citizens, particularly children, from online exploitation and criminal activities. With the digital landscape becoming increasingly integral to daily life, the EU aims to strengthen its ability to combat serious crimes facilitated through online platforms.

Protecting Children and Preventing Crime

One of the primary motivations behind Chat Control is the prevention of child sexual abuse material (CSAM) circulating on the internet. Law enforcement agencies have reported a significant increase in the sharing of illegal content through private messaging services. By implementing Chat Control, the EU believes it can more effectively identify and stop perpetrators, rescue victims, and deter future crimes.

Terrorism is another critical concern. Encrypted messaging apps can be used by terrorist groups to plan and coordinate attacks without detection. The EU argues that accessing these communications could be vital in preventing such threats and ensuring public safety.

Legal Context and Legislative Drivers

The push for Chat Control is rooted in several legislative initiatives:

• ePrivacy Directive: This directive regulates the processing of personal data and the protection of privacy in electronic communications. The EU is considering amendments that would allow for the scanning of private messages under specific circumstances.

• Temporary Derogation: In 2021, the EU adopted a temporary regulation permitting voluntary detection of CSAM by communication services. The current proposals aim to make such measures mandatory and more comprehensive.

• Regulation Proposals: The European Commission has proposed regulations that would require service providers to detect, report, and remove illegal content proactively. This would include the use of technologies to scan private communications.

Balancing Security and Privacy

EU officials argue that the proposed measures are a necessary response to evolving digital threats. They emphasize the importance of staying ahead of criminals who exploit technology to harm others. By implementing Chat Control, they believe law enforcement can be more effective without entirely dismantling privacy protections.

However, the EU also acknowledges the need to balance security with fundamental rights. The proposals include provisions intended to limit the scope of surveillance, such as:

• Targeted Scanning: Focusing on specific threats rather than broad, indiscriminate monitoring.

• Judicial Oversight: Requiring court orders or oversight for accessing private communications.

• Data Protection Safeguards: Implementing measures to ensure that data collected is handled securely and deleted when no longer needed.

The Urgency Behind the Push

High-profile cases of online abuse and terrorism have heightened the sense of urgency among EU policymakers. Reports of increasing online grooming and the widespread distribution of illegal content have prompted calls for immediate action. The EU posits that without measures like Chat Control, these problems will continue to escalate unchecked.

Criticism and Controversy

Despite the stated intentions, the push for Chat Control has been met with significant criticism. Opponents argue that the measures could be ineffective against savvy criminals who can find alternative ways to communicate. There is also concern that such surveillance could be misused or extended beyond its original purpose.

---

The Privacy Concerns and Risks

While the intentions behind Chat Control focus on enhancing security and protecting vulnerable groups, the proposed measures raise significant privacy concerns. Critics argue that implementing such surveillance could infringe on fundamental rights and set a dangerous precedent for mass monitoring of private communications.

Infringement on Privacy Rights

At the heart of the debate is the right to privacy. By scanning private messages, even with automated tools, the confidentiality of personal communications is compromised. Users may no longer feel secure sharing sensitive information, fearing that their messages could be intercepted or misinterpreted by algorithms.

Erosion of End-to-End Encryption

End-to-end encryption (E2EE) is a cornerstone of digital security, ensuring that only the sender and recipient can read the messages exchanged. Chat Control could necessitate the introduction of "backdoors" or weaken encryption protocols, making it easier for unauthorized parties to access private data. This not only affects individual privacy but also exposes communications to potential cyber threats.

Concerns from Privacy Advocates

Organizations like Signal and Tutanota, which offer encrypted messaging services, have voiced strong opposition to Chat Control. They warn that undermining encryption could have far-reaching consequences:

• Security Risks: Weakening encryption makes systems more vulnerable to hacking, espionage, and cybercrime.
• Global Implications: Changes in EU regulations could influence policies worldwide, leading to a broader erosion of digital privacy.
• Ineffectiveness Against Crime: Determined criminals might resort to other, less detectable means of communication, rendering the measures ineffective while still compromising the privacy of law-abiding citizens.

Potential for Government Overreach

There is a fear that Chat Control could lead to increased surveillance beyond its original scope. Once the infrastructure for scanning private messages is in place, it could be repurposed or expanded to monitor other types of content, stifling free expression and dissent.

Real-World Implications for Users

• False Positives: Automated scanning technologies are not infallible and could mistakenly flag innocent content, leading to unwarranted scrutiny or legal consequences for users.
• Chilling Effect: Knowing that messages could be monitored might discourage people from expressing themselves freely, impacting personal relationships and societal discourse.
• Data Misuse: Collected data could be vulnerable to leaks or misuse, compromising personal and sensitive information.

Legal and Ethical Concerns

Privacy advocates also highlight potential conflicts with existing laws and ethical standards:

• Violation of Fundamental Rights: The European Convention on Human Rights and other international agreements protect the right to privacy and freedom of expression.
• Questionable Effectiveness: The ethical justification for such invasive measures is challenged if they do not significantly improve safety or if they disproportionately impact innocent users.

Opposition from Member States and Organizations

Countries like Germany and organizations such as the European Digital Rights (EDRi) have expressed opposition to Chat Control. They emphasize the need to protect digital privacy and caution against hasty legislation that could have unintended consequences.

---

The Technical Debate: Encryption and Backdoors

The discussion around Chat Control inevitably leads to a complex technical debate centered on encryption and the potential introduction of backdoors into secure communication systems. Understanding these concepts is crucial to grasping the full implications of the proposed measures.

What Is End-to-End Encryption (E2EE)?

End-to-end encryption is a method of secure communication that prevents third parties from accessing data while it's transferred from one end system to another. In simpler terms, only the sender and the recipient can read the messages. Even the service providers operating the messaging platforms cannot decrypt the content.

• Security Assurance: E2EE ensures that sensitive information—be it personal messages, financial details, or confidential business communications—remains private.
• Widespread Use: Popular messaging apps like Signal, Session, SimpleX, Veilid, Protonmail and Tutanota (among others) rely on E2EE to protect user data.

How Chat Control Affects Encryption

Implementing Chat Control as proposed would require messaging services to scan the content of messages for illegal material. To do this on encrypted platforms, providers might have to:

• Introduce Backdoors: Create a means for third parties (including the service provider or authorities) to access encrypted messages.
• Client-Side Scanning: Install software on users' devices that scans messages before they are encrypted and sent, effectively bypassing E2EE.

The Risks of Weakening Encryption

1. Compromised Security for All Users

Introducing backdoors or client-side scanning tools can create vulnerabilities:

• Exploitable Gaps: If a backdoor exists, malicious actors might find and exploit it, leading to data breaches.
• Universal Impact: Weakening encryption doesn't just affect targeted individuals; it potentially exposes all users to increased risk.

2. Undermining Trust in Digital Services

• User Confidence: Knowing that private communications could be accessed might deter people from using digital services or push them toward unregulated platforms.
• Business Implications: Companies relying on secure communications might face increased risks, affecting economic activities.

3. Ineffectiveness Against Skilled Adversaries

• Alternative Methods: Criminals might shift to other encrypted channels or develop new ways to avoid detection.
• False Sense of Security: Weakening encryption could give the impression of increased safety while adversaries adapt and continue their activities undetected.

Signal’s Response and Stance

Signal, a leading encrypted messaging service, has been vocal in its opposition to the EU's proposals:

• Refusal to Weaken Encryption: Signal's CEO Meredith Whittaker has stated that the company would rather cease operations in the EU than compromise its encryption standards.
• Advocacy for Privacy: Signal emphasizes that strong encryption is essential for protecting human rights and freedoms in the digital age.

Understanding Backdoors

A "backdoor" in encryption is an intentional weakness inserted into a system to allow authorized access to encrypted data. While intended for legitimate use by authorities, backdoors pose several problems:

• Security Vulnerabilities: They can be discovered and exploited by unauthorized parties, including hackers and foreign governments.
• Ethical Concerns: The existence of backdoors raises questions about consent and the extent to which governments should be able to access private communications.

The Slippery Slope Argument

Privacy advocates warn that introducing backdoors or mandatory scanning sets a precedent:

• Expanded Surveillance: Once in place, these measures could be extended to monitor other types of content beyond the original scope.
• Erosion of Rights: Gradual acceptance of surveillance can lead to a significant reduction in personal freedoms over time.

Potential Technological Alternatives

Some suggest that it's possible to fight illegal content without undermining encryption:

• Metadata Analysis: Focusing on patterns of communication rather than content.
• Enhanced Reporting Mechanisms: Encouraging users to report illegal content voluntarily.
• Investing in Law Enforcement Capabilities: Strengthening traditional investigative methods without compromising digital security.

The technical community largely agrees that weakening encryption is not the solution:

• Consensus on Security: Strong encryption is essential for the safety and privacy of all internet users.
• Call for Dialogue: Technologists and privacy experts advocate for collaborative approaches that address security concerns without sacrificing fundamental rights.

---

Global Reactions and the Debate in Europe

The proposal for Chat Control has ignited a heated debate across Europe and beyond, with various stakeholders weighing in on the potential implications for privacy, security, and fundamental rights. The reactions are mixed, reflecting differing national perspectives, political priorities, and societal values.

Support for Chat Control

Some EU member states and officials support the initiative, emphasizing the need for robust measures to combat online crime and protect citizens, especially children. They argue that:

• Enhanced Security: Mandatory scanning can help law enforcement agencies detect and prevent serious crimes.
• Responsibility of Service Providers: Companies offering communication services should play an active role in preventing their platforms from being used for illegal activities.
• Public Safety Priorities: The protection of vulnerable populations justifies the implementation of such measures, even if it means compromising some aspects of privacy.

Opposition within the EU

Several countries and organizations have voiced strong opposition to Chat Control, citing concerns over privacy rights and the potential for government overreach.

Germany

• Stance: Germany has been one of the most vocal opponents of the proposed measures.
• Reasons:
• Constitutional Concerns: The German government argues that Chat Control could violate constitutional protections of privacy and confidentiality of communications.
• Security Risks: Weakening encryption is seen as a threat to cybersecurity.
• Legal Challenges: Potential conflicts with national laws protecting personal data and communication secrecy.

Netherlands

• Recent Developments: The Dutch government decided against supporting Chat Control, emphasizing the importance of encryption for security and privacy.
• Arguments:
• Effectiveness Doubts: Skepticism about the actual effectiveness of the measures in combating crime.
• Negative Impact on Privacy: Concerns about mass surveillance and the infringement of citizens' rights.

Table reference: Patrick Breyer - Chat Control in 23 September 2024

Privacy Advocacy Groups

European Digital Rights (EDRi)

• Role: A network of civil and human rights organizations working to defend rights and freedoms in the digital environment.
• Position:
• Strong Opposition: EDRi argues that Chat Control is incompatible with fundamental rights.
• Awareness Campaigns: Engaging in public campaigns to inform citizens about the potential risks.
• Policy Engagement: Lobbying policymakers to consider alternative approaches that respect privacy.

Politicians and Activists

Patrick Breyer

• Background: A Member of the European Parliament (MEP) from Germany, representing the Pirate Party.
• Actions:
• Advocacy: Actively campaigning against Chat Control through speeches, articles, and legislative efforts.
• Public Outreach: Using social media and public events to raise awareness.
• Legal Expertise: Highlighting the legal inconsistencies and potential violations of EU law.

Global Reactions

International Organizations

• Human Rights Watch and Amnesty International: These organizations have expressed concerns about the implications for human rights, urging the EU to reconsider.

Technology Companies

• Global Tech Firms: Companies like Apple and Microsoft are monitoring the situation, as EU regulations could affect their operations and user trust.
• Industry Associations: Groups representing tech companies have issued statements highlighting the risks to innovation and competitiveness.

The Broader Debate

The controversy over Chat Control reflects a broader struggle between security interests and privacy rights in the digital age. Key points in the debate include:

• Legal Precedents: How the EU's decision might influence laws and regulations in other countries.
• Digital Sovereignty: The desire of nations to control digital spaces within their borders.
• Civil Liberties: The importance of protecting freedoms in the face of technological advancements.

Public Opinion

• Diverse Views: Surveys and public forums show a range of opinions, with some citizens prioritizing security and others valuing privacy above all.
• Awareness Levels: Many people are still unaware of the potential changes, highlighting the need for public education on the issue.

The EU is at a crossroads, facing the challenge of addressing legitimate security concerns without undermining the fundamental rights that are central to its values. The outcome of this debate will have significant implications for the future of digital privacy and the balance between security and freedom in society.

---

Possible Consequences for Messaging Services

The implementation of Chat Control could have significant implications for messaging services operating within the European Union. Both large platforms and smaller providers might need to adapt their technologies and policies to comply with the new regulations, potentially altering the landscape of digital communication.

Impact on Encrypted Messaging Services

Signal and Similar Platforms

• Compliance Challenges: Encrypted messaging services like Signal rely on end-to-end encryption to secure user communications. Complying with Chat Control could force them to weaken their encryption protocols or implement client-side scanning, conflicting with their core privacy principles.

• Operational Decisions: Some platforms may choose to limit their services in the EU or cease operations altogether rather than compromise on encryption. Signal, for instance, has indicated that it would prefer to withdraw from European markets than undermine its security features.

Potential Blocking or Limiting of Services

• Regulatory Enforcement: Messaging services that do not comply with Chat Control regulations could face fines, legal action, or even be blocked within the EU.

• Access Restrictions: Users in Europe might find certain services unavailable or limited in functionality if providers decide not to meet the regulatory requirements.

Effects on Smaller Providers

• Resource Constraints: Smaller messaging services and startups may lack the resources to implement the required scanning technologies, leading to increased operational costs or forcing them out of the market.

• Innovation Stifling: The added regulatory burden could deter new entrants, reducing competition and innovation in the messaging service sector.

User Experience and Trust

• Privacy Concerns: Users may lose trust in messaging platforms if they know their communications are subject to scanning, leading to a decline in user engagement.

• Migration to Unregulated Platforms: There is a risk that users might shift to less secure or unregulated services, including those operated outside the EU or on the dark web, potentially exposing them to greater risks.

Technical and Security Implications

• Increased Vulnerabilities: Modifying encryption protocols to comply with Chat Control could introduce security flaws, making platforms more susceptible to hacking and data breaches.

• Global Security Risks: Changes made to accommodate EU regulations might affect the global user base of these services, extending security risks beyond European borders.

Impact on Businesses and Professional Communications

• Confidentiality Issues: Businesses that rely on secure messaging for sensitive communications may face challenges in ensuring confidentiality, affecting sectors like finance, healthcare, and legal services.

• Compliance Complexity: Companies operating internationally will need to navigate a complex landscape of differing regulations, increasing administrative burdens.

Economic Consequences

• Market Fragmentation: Divergent regulations could lead to a fragmented market, with different versions of services for different regions.

• Loss of Revenue: Messaging services might experience reduced revenue due to decreased user trust and engagement or the costs associated with compliance.

Responses from Service Providers

• Legal Challenges: Companies might pursue legal action against the regulations, citing conflicts with privacy laws and user rights.

• Policy Advocacy: Service providers may increase lobbying efforts to influence policy decisions and promote alternatives to Chat Control.

Possible Adaptations

• Technological Innovation: Some providers might invest in developing new technologies that can detect illegal content without compromising encryption, though the feasibility remains uncertain.

• Transparency Measures: To maintain user trust, companies might enhance transparency about how data is handled and what measures are in place to protect privacy.

The potential consequences of Chat Control for messaging services are profound, affecting not only the companies that provide these services but also the users who rely on them daily. The balance between complying with legal requirements and maintaining user privacy and security presents a significant challenge that could reshape the digital communication landscape.

---

What Happens Next? The Future of Chat Control

The future of Chat Control remains uncertain as the debate continues among EU member states, policymakers, technology companies, and civil society organizations. Several factors will influence the outcome of this contentious proposal, each carrying significant implications for digital privacy, security, and the regulatory environment within the European Union.

Current Status of Legislation

• Ongoing Negotiations: The proposed Chat Control measures are still under discussion within the European Parliament and the Council of the European Union. Amendments and revisions are being considered in response to the feedback from various stakeholders.

• Timeline: While there is no fixed date for the final decision, the EU aims to reach a consensus to implement effective measures against online crime without undue delay.

Key Influencing Factors

1. Legal Challenges and Compliance with EU Law

• Fundamental Rights Assessment: The proposals must be evaluated against the Charter of Fundamental Rights of the European Union, ensuring that any measures comply with rights to privacy, data protection, and freedom of expression.

• Court Scrutiny: Potential legal challenges could arise, leading to scrutiny by the European Court of Justice (ECJ), which may impact the feasibility and legality of Chat Control.

2. Technological Feasibility

• Development of Privacy-Preserving Technologies: Research into methods that can detect illegal content without compromising encryption is ongoing. Advances in this area could provide alternative solutions acceptable to both privacy advocates and security agencies.

• Implementation Challenges: The practical aspects of deploying scanning technologies across various platforms and services remain complex, and technical hurdles could delay or alter the proposed measures.

3. Political Dynamics

• Member State Positions: The differing stances of EU countries, such as Germany's opposition, play a significant role in shaping the final outcome. Consensus among member states is crucial for adopting EU-wide regulations.

• Public Opinion and Advocacy: Growing awareness and activism around digital privacy can influence policymakers. Public campaigns and lobbying efforts may sway decisions in favor of stronger privacy protections.

4. Industry Responses

• Negotiations with Service Providers: Ongoing dialogues between EU authorities and technology companies may lead to compromises or collaborative efforts to address concerns without fully implementing Chat Control as initially proposed.

• Potential for Self-Regulation: Messaging services might propose self-regulatory measures to combat illegal content, aiming to demonstrate effectiveness without the need for mandatory scanning.

Possible Scenarios

Optimistic Outcome:

• Balanced Regulation: A revised proposal emerges that effectively addresses security concerns while upholding strong encryption and privacy rights, possibly through innovative technologies or targeted measures with robust oversight.

Pessimistic Outcome:

• Adoption of Strict Measures: Chat Control is implemented as initially proposed, leading to weakened encryption, reduced privacy, and potential withdrawal of services like Signal from the EU market.

Middle Ground:

• Incremental Implementation: Partial measures are adopted, focusing on voluntary cooperation with service providers and emphasizing transparency and user consent, with ongoing evaluations to assess effectiveness and impact.

How to Stay Informed and Protect Your Privacy

• Follow Reputable Sources: Keep up with news from reliable outlets, official EU communications, and statements from privacy organizations to stay informed about developments.

• Engage in the Dialogue: Participate in public consultations, sign petitions, or contact representatives to express your views on Chat Control and digital privacy.

• Utilize Secure Practices: Regardless of legislative outcomes, adopting good digital hygiene—such as using strong passwords and being cautious with personal information—can enhance your online security.

The Global Perspective

• International Implications: The EU's decision may influence global policies on encryption and surveillance, setting precedents that other countries might follow or react against.

• Collaboration Opportunities: International cooperation on developing solutions that protect both security and privacy could emerge, fostering a more unified approach to addressing online threats.

Looking Ahead

The future of Chat Control is a critical issue that underscores the challenges of governing in the digital age. Balancing the need for security with the protection of fundamental rights is a complex task that requires careful consideration, open dialogue, and collaboration among all stakeholders.

As the situation evolves, staying informed and engaged is essential. The decisions made in the coming months will shape the digital landscape for years to come, affecting how we communicate, conduct business, and exercise our rights in an increasingly connected world.

---

Conclusion

The debate over Chat Control highlights a fundamental challenge in our increasingly digital world: how to protect society from genuine threats without eroding the very rights and freedoms that define it. While the intention to safeguard children and prevent crime is undeniably important, the means of achieving this through intrusive surveillance measures raise critical concerns.

Privacy is not just a personal preference but a cornerstone of democratic societies. End-to-end encryption has become an essential tool for ensuring that our personal conversations, professional communications, and sensitive data remain secure from unwanted intrusion. Weakening these protections could expose individuals and organizations to risks that far outweigh the proposed benefits.

The potential consequences of implementing Chat Control are far-reaching:

• Erosion of Trust: Users may lose confidence in digital platforms, impacting how we communicate and conduct business online.
• Security Vulnerabilities: Introducing backdoors or weakening encryption can make systems more susceptible to cyberattacks.
• Stifling Innovation: Regulatory burdens may hinder technological advancement and competitiveness in the tech industry.
• Global Implications: The EU's decisions could set precedents that influence digital policies worldwide, for better or worse.

As citizens, it's crucial to stay informed about these developments. Engage in conversations, reach out to your representatives, and advocate for solutions that respect both security needs and fundamental rights. Technology and policy can evolve together to address challenges without compromising core values.

The future of Chat Control is not yet decided, and public input can make a significant difference. By promoting open dialogue, supporting privacy-preserving innovations, and emphasizing the importance of human rights in legislation, we can work towards a digital landscape that is both safe and free.

In a world where digital communication is integral to daily life, striking the right balance between security and privacy is more important than ever. The choices made today will shape the digital environment for generations to come, determining not just how we communicate, but how we live and interact in an interconnected world.

---

Thank you for reading this article. We hope it has provided you with a clear understanding of Chat Control and its potential impact on your privacy and digital rights. Stay informed, stay engaged, and let's work together towards a secure and open digital future.

Read more:

• https://www.patrick-breyer.de/en/posts/chat-control/
• https://www.patrick-breyer.de/en/new-eu-push-for-chat-control-will-messenger-services-be-blocked-in-europe/
• https://edri.org/our-work/dutch-decision-puts-brakes-on-chat-control/
• https://signal.org/blog/pdfs/ndss-keynote.pdf
• https://tuta.com/blog/germany-stop-chat-control
• https://cointelegraph.com/news/signal-president-slams-revised-eu-encryption-proposal
• https://mullvad.net/en/why-privacy-matters

@ 4ba8e86d:89d32de4

O que é Cwtch? Cwtch (/kʊtʃ/ - uma palavra galesa que pode ser traduzida aproximadamente como “um abraço que cria um lugar seguro”) é um protocolo de mensagens multipartidário descentralizado, que preserva a privacidade, que pode ser usado para construir aplicativos resistentes a metadados.

Como posso pronunciar Cwtch? Como "kutch", para rimar com "butch".

Descentralizado e Aberto : Não existe “serviço Cwtch” ou “rede Cwtch”. Os participantes do Cwtch podem hospedar seus próprios espaços seguros ou emprestar sua infraestrutura para outras pessoas que buscam um espaço seguro. O protocolo Cwtch é aberto e qualquer pessoa é livre para criar bots, serviços e interfaces de usuário e integrar e interagir com o Cwtch.

Preservação de privacidade : toda a comunicação no Cwtch é criptografada de ponta a ponta e ocorre nos serviços cebola Tor v3.

Resistente a metadados : O Cwtch foi projetado de forma que nenhuma informação seja trocada ou disponibilizada a ninguém sem seu consentimento explícito, incluindo mensagens durante a transmissão e metadados de protocolo

Uma breve história do bate-papo resistente a metadados Nos últimos anos, a conscientização pública sobre a necessidade e os benefícios das soluções criptografadas de ponta a ponta aumentou com aplicativos como Signal , Whatsapp e Wire. que agora fornecem aos usuários comunicações seguras.

No entanto, essas ferramentas exigem vários níveis de exposição de metadados para funcionar, e muitos desses metadados podem ser usados ​​para obter detalhes sobre como e por que uma pessoa está usando uma ferramenta para se comunicar.

Uma ferramenta que buscou reduzir metadados é o Ricochet lançado pela primeira vez em 2014. Ricochet usou os serviços cebola Tor v2 para fornecer comunicação criptografada segura de ponta a ponta e para proteger os metadados das comunicações.

Não havia servidores centralizados que auxiliassem no roteamento das conversas do Ricochet. Ninguém além das partes envolvidas em uma conversa poderia saber que tal conversa está ocorrendo.

Ricochet tinha limitações; não havia suporte para vários dispositivos, nem existe um mecanismo para suportar a comunicação em grupo ou para um usuário enviar mensagens enquanto um contato está offline.

Isto tornou a adoção do Ricochet uma proposta difícil; mesmo aqueles em ambientes que seriam melhor atendidos pela resistência aos metadados, sem saber que ela existe.

Além disso, qualquer solução para comunicação descentralizada e resistente a metadados enfrenta problemas fundamentais quando se trata de eficiência, privacidade e segurança de grupo conforme definido pelo consenso e consistência da transcrição.

Alternativas modernas ao Ricochet incluem Briar , Zbay e Ricochet Refresh - cada ferramenta procura otimizar para um conjunto diferente de compensações, por exemplo, Briar procura permitir que as pessoas se comuniquem mesmo quando a infraestrutura de rede subjacente está inoperante, ao mesmo tempo que fornece resistência à vigilância de metadados.

O projeto Cwtch começou em 2017 como um protocolo de extensão para Ricochet, fornecendo conversas em grupo por meio de servidores não confiáveis, com o objetivo de permitir aplicativos descentralizados e resistentes a metadados como listas compartilhadas e quadros de avisos.

Uma versão alfa do Cwtch foi lançada em fevereiro de 2019 e, desde então, a equipe do Cwtch dirigida pela OPEN PRIVACY RESEARCH SOCIETY conduziu pesquisa e desenvolvimento em cwtch e nos protocolos, bibliotecas e espaços de problemas subjacentes.

Modelo de Risco.

Sabe-se que os metadados de comunicações são explorados por vários adversários para minar a segurança dos sistemas, para rastrear vítimas e para realizar análises de redes sociais em grande escala para alimentar a vigilância em massa. As ferramentas resistentes a metadados estão em sua infância e faltam pesquisas sobre a construção e a experiência do usuário de tais ferramentas.

https://nostrcheck.me/media/public/nostrcheck.me_9475702740746681051707662826.webp

O Cwtch foi originalmente concebido como uma extensão do protocolo Ricochet resistente a metadados para suportar comunicações assíncronas de grupos multiponto por meio do uso de infraestrutura anônima, descartável e não confiável.

Desde então, o Cwtch evoluiu para um protocolo próprio. Esta seção descreverá os vários riscos conhecidos que o Cwtch tenta mitigar e será fortemente referenciado no restante do documento ao discutir os vários subcomponentes da Arquitetura Cwtch.

Modelo de ameaça.

É importante identificar e compreender que os metadados são omnipresentes nos protocolos de comunicação; é de facto necessário que tais protocolos funcionem de forma eficiente e em escala. No entanto, as informações que são úteis para facilitar peers e servidores também são altamente relevantes para adversários que desejam explorar tais informações.

Para a definição do nosso problema, assumiremos que o conteúdo de uma comunicação é criptografado de tal forma que um adversário é praticamente incapaz de quebrá-lo veja tapir e cwtch para detalhes sobre a criptografia que usamos, e como tal nos concentraremos em o contexto para os metadados de comunicação.

Procuramos proteger os seguintes contextos de comunicação:

• Quem está envolvido em uma comunicação? Pode ser possível identificar pessoas ou simplesmente identificadores de dispositivos ou redes. Por exemplo, “esta comunicação envolve Alice, uma jornalista, e Bob, um funcionário público”.

• Onde estão os participantes da conversa? Por exemplo, “durante esta comunicação, Alice estava na França e Bob estava no Canadá”.

• Quando ocorreu uma conversa? O momento e a duração da comunicação podem revelar muito sobre a natureza de uma chamada, por exemplo, “Bob, um funcionário público, conversou com Alice ao telefone por uma hora ontem à noite. Esta é a primeira vez que eles se comunicam.” *Como a conversa foi mediada? O fato de uma conversa ter ocorrido por meio de um e-mail criptografado ou não criptografado pode fornecer informações úteis. Por exemplo, “Alice enviou um e-mail criptografado para Bob ontem, enquanto eles normalmente enviam apenas e-mails de texto simples um para o outro”.

• Sobre o que é a conversa? Mesmo que o conteúdo da comunicação seja criptografado, às vezes é possível derivar um contexto provável de uma conversa sem saber exatamente o que é dito, por exemplo, “uma pessoa ligou para uma pizzaria na hora do jantar” ou “alguém ligou para um número conhecido de linha direta de suicídio na hora do jantar”. 3 horas da manhã."

Além das conversas individuais, também procuramos defender-nos contra ataques de correlação de contexto, através dos quais múltiplas conversas são analisadas para obter informações de nível superior:

• Relacionamentos: Descobrir relações sociais entre um par de entidades analisando a frequência e a duração de suas comunicações durante um período de tempo. Por exemplo, Carol e Eve ligam uma para a outra todos os dias durante várias horas seguidas.

• Cliques: Descobrir relações sociais entre um grupo de entidades que interagem entre si. Por exemplo, Alice, Bob e Eva se comunicam entre si.

• Grupos vagamente conectados e indivíduos-ponte: descobrir grupos que se comunicam entre si através de intermediários, analisando cadeias de comunicação (por exemplo, toda vez que Alice fala com Bob, ela fala com Carol quase imediatamente depois; Bob e Carol nunca se comunicam).

• Padrão de Vida: Descobrir quais comunicações são cíclicas e previsíveis. Por exemplo, Alice liga para Eve toda segunda-feira à noite por cerca de uma hora. Ataques Ativos

Ataques de deturpação.

O Cwtch não fornece registro global de nomes de exibição e, como tal, as pessoas que usam o Cwtch são mais vulneráveis ​​a ataques baseados em declarações falsas, ou seja, pessoas que fingem ser outras pessoas:

O fluxo básico de um desses ataques é o seguinte, embora também existam outros fluxos:

•Alice tem um amigo chamado Bob e outro chamado Eve

• Eve descobre que Alice tem um amigo chamado Bob

• Eve cria milhares de novas contas para encontrar uma que tenha uma imagem/chave pública semelhante à de Bob (não será idêntica, mas pode enganar alguém por alguns minutos)

• Eve chama essa nova conta de "Eve New Account" e adiciona Alice como amiga.

• Eve então muda seu nome em "Eve New Account" para "Bob"

• Alice envia mensagens destinadas a "Bob" para a conta falsa de Bob de Eve Como os ataques de declarações falsas são inerentemente uma questão de confiança e verificação, a única maneira absoluta de evitá-los é os usuários validarem absolutamente a chave pública. Obviamente, isso não é o ideal e, em muitos casos, simplesmente não acontecerá .

Como tal, pretendemos fornecer algumas dicas de experiência do usuário na interface do usuário para orientar as pessoas na tomada de decisões sobre confiar em contas e/ou distinguir contas que possam estar tentando se representar como outros usuários.

Uma nota sobre ataques físicos A Cwtch não considera ataques que exijam acesso físico (ou equivalente) à máquina do usuário como praticamente defensáveis. No entanto, no interesse de uma boa engenharia de segurança, ao longo deste documento ainda nos referiremos a ataques ou condições que exigem tal privilégio e indicaremos onde quaisquer mitigações que implementámos falharão.

Um perfil Cwtch.

Os usuários podem criar um ou mais perfis Cwtch. Cada perfil gera um par de chaves ed25519 aleatório compatível com Tor.

Além do material criptográfico, um perfil também contém uma lista de Contatos (outras chaves públicas do perfil Cwtch + dados associados sobre esse perfil, como apelido e (opcionalmente) mensagens históricas), uma lista de Grupos (contendo o material criptográfico do grupo, além de outros dados associados, como apelido do grupo e mensagens históricas).

Conversões entre duas partes: ponto a ponto

https://nostrcheck.me/media/public/nostrcheck.me_2186338207587396891707662879.webp

Para que duas partes participem de uma conversa ponto a ponto, ambas devem estar on-line, mas apenas uma precisa estar acessível por meio do serviço Onion. Por uma questão de clareza, muitas vezes rotulamos uma parte como “ponto de entrada” (aquele que hospeda o serviço cebola) e a outra parte como “ponto de saída” (aquele que se conecta ao serviço cebola).

Após a conexão, ambas as partes adotam um protocolo de autenticação que:

• Afirma que cada parte tem acesso à chave privada associada à sua identidade pública.

• Gera uma chave de sessão efêmera usada para criptografar todas as comunicações futuras durante a sessão.

Esta troca (documentada com mais detalhes no protocolo de autenticação ) é negável offline , ou seja, é possível para qualquer parte falsificar transcrições desta troca de protocolo após o fato e, como tal - após o fato - é impossível provar definitivamente que a troca aconteceu de forma alguma.

Após o protocolo de autenticação, as duas partes podem trocar mensagens livremente.

Conversas em Grupo e Comunicação Ponto a Servidor

Ao iniciar uma conversa em grupo, é gerada uma chave aleatória para o grupo, conhecida como Group Key. Todas as comunicações do grupo são criptografadas usando esta chave. Além disso, o criador do grupo escolhe um servidor Cwtch para hospedar o grupo. Um convite é gerado, incluindo o Group Key, o servidor do grupo e a chave do grupo, para ser enviado aos potenciais membros.

Para enviar uma mensagem ao grupo, um perfil se conecta ao servidor do grupo e criptografa a mensagem usando a Group Key, gerando também uma assinatura sobre o Group ID, o servidor do grupo e a mensagem. Para receber mensagens do grupo, um perfil se conecta ao servidor e baixa as mensagens, tentando descriptografá-las usando a Group Key e verificando a assinatura.

Detalhamento do Ecossistema de Componentes

O Cwtch é composto por várias bibliotecas de componentes menores, cada uma desempenhando um papel específico. Algumas dessas bibliotecas incluem:

• abertoprivacidade/conectividade: Abstração de rede ACN, atualmente suportando apenas Tor.
• cwtch.im/tapir: Biblioteca para construção de aplicativos p2p em sistemas de comunicação anônimos.
• cwtch.im/cwtch: Biblioteca principal para implementação do protocolo/sistema Cwtch.
• cwtch.im/libcwtch-go: Fornece ligações C para Cwtch para uso em implementações de UI.

TAPIR: Uma Visão Detalhada

Projetado para substituir os antigos canais de ricochete baseados em protobuf, o Tapir fornece uma estrutura para a construção de aplicativos anônimos.

Está dividido em várias camadas:

• Identidade - Um par de chaves ed25519, necessário para estabelecer um serviço cebola Tor v3 e usado para manter uma identidade criptográfica consistente para um par.

• Conexões – O protocolo de rede bruto que conecta dois pares. Até agora, as conexões são definidas apenas através do Tor v3 Onion Services.

• Aplicativos - As diversas lógicas que permitem um determinado fluxo de informações em uma conexão. Os exemplos incluem transcrições criptográficas compartilhadas, autenticação, proteção contra spam e serviços baseados em tokens. Os aplicativos fornecem recursos que podem ser referenciados por outros aplicativos para determinar se um determinado peer tem a capacidade de usar um determinado aplicativo hospedado.

• Pilhas de aplicativos - Um mecanismo para conectar mais de um aplicativo, por exemplo, a autenticação depende de uma transcrição criptográfica compartilhada e o aplicativo peer cwtch principal é baseado no aplicativo de autenticação.

Identidade.

Um par de chaves ed25519, necessário para estabelecer um serviço cebola Tor v3 e usado para manter uma identidade criptográfica consistente para um peer.

InitializeIdentity - de um par de chaves conhecido e persistente:i,I

InitializeEphemeralIdentity - de um par de chaves aleatório: ie,Ie

Aplicativos de transcrição.

Inicializa uma transcrição criptográfica baseada em Merlin que pode ser usada como base de protocolos baseados em compromisso de nível superior

O aplicativo de transcrição entrará em pânico se um aplicativo tentar substituir uma transcrição existente por uma nova (aplicando a regra de que uma sessão é baseada em uma e apenas uma transcrição).

Merlin é uma construção de transcrição baseada em STROBE para provas de conhecimento zero. Ele automatiza a transformação Fiat-Shamir, para que, usando Merlin, protocolos não interativos possam ser implementados como se fossem interativos.

Isto é significativamente mais fácil e menos sujeito a erros do que realizar a transformação manualmente e, além disso, também fornece suporte natural para:

• protocolos multi-round com fases alternadas de commit e desafio;

• separação natural de domínios, garantindo que os desafios estejam vinculados às afirmações a serem provadas;

• enquadramento automático de mensagens, evitando codificação ambígua de dados de compromisso;

• e composição do protocolo, usando uma transcrição comum para vários protocolos.

Finalmente, o Merlin também fornece um gerador de números aleatórios baseado em transcrição como defesa profunda contra ataques de entropia ruim (como reutilização de nonce ou preconceito em muitas provas). Este RNG fornece aleatoriedade sintética derivada de toda a transcrição pública, bem como dos dados da testemunha do provador e uma entrada auxiliar de um RNG externo.

Conectividade Cwtch faz uso do Tor Onion Services (v3) para todas as comunicações entre nós.

Fornecemos o pacote openprivacy/connectivity para gerenciar o daemon Tor e configurar e desmontar serviços cebola através do Tor.

Criptografia e armazenamento de perfil.

Os perfis são armazenados localmente no disco e criptografados usando uma chave derivada de uma senha conhecida pelo usuário (via pbkdf2).

Observe que, uma vez criptografado e armazenado em disco, a única maneira de recuperar um perfil é recuperando a senha - como tal, não é possível fornecer uma lista completa de perfis aos quais um usuário pode ter acesso até inserir uma senha.

Perfis não criptografados e a senha padrão Para lidar com perfis "não criptografados" (ou seja, que não exigem senha para serem abertos), atualmente criamos um perfil com uma senha codificada de fato .

Isso não é o ideal, preferiríamos confiar no material de chave fornecido pelo sistema operacional, de modo que o perfil fosse vinculado a um dispositivo específico, mas esses recursos são atualmente uma colcha de retalhos - também notamos, ao criar um perfil não criptografado, pessoas que usam Cwtch estão explicitamente optando pelo risco de que alguém com acesso ao sistema de arquivos possa descriptografar seu perfil.

Vulnerabilidades Relacionadas a Imagens e Entrada de Dados

Imagens Maliciosas

O Cwtch enfrenta desafios na renderização de imagens, com o Flutter utilizando Skia, embora o código subjacente não seja totalmente seguro para a memória.

Realizamos testes de fuzzing nos componentes Cwtch e encontramos um bug de travamento causado por um arquivo GIF malformado, levando a falhas no kernel. Para mitigar isso, adotamos a política de sempre habilitar cacheWidth e/ou cacheHeight máximo para widgets de imagem.

Identificamos o risco de imagens maliciosas serem renderizadas de forma diferente em diferentes plataformas, como evidenciado por um bug no analisador PNG da Apple.

Riscos de Entrada de Dados

Um risco significativo é a interceptação de conteúdo ou metadados por meio de um Input Method Editor (IME) em dispositivos móveis. Mesmo aplicativos IME padrão podem expor dados por meio de sincronização na nuvem, tradução online ou dicionários pessoais.

Implementamos medidas de mitigação, como enableIMEPersonalizedLearning: false no Cwtch 1.2, mas a solução completa requer ações em nível de sistema operacional e é um desafio contínuo para a segurança móvel.

Servidor Cwtch.

O objetivo do protocolo Cwtch é permitir a comunicação em grupo através de infraestrutura não confiável .

Ao contrário dos esquemas baseados em retransmissão, onde os grupos atribuem um líder, um conjunto de líderes ou um servidor confiável de terceiros para garantir que cada membro do grupo possa enviar e receber mensagens em tempo hábil (mesmo que os membros estejam offline) - infraestrutura não confiável tem o objetivo de realizar essas propriedades sem a suposição de confiança.

O artigo original do Cwtch definia um conjunto de propriedades que se esperava que os servidores Cwtch fornecessem:

• O Cwtch Server pode ser usado por vários grupos ou apenas um.

• Um servidor Cwtch, sem a colaboração de um membro do grupo, nunca deve aprender a identidade dos participantes de um grupo.

• Um servidor Cwtch nunca deve aprender o conteúdo de qualquer comunicação.

• Um servidor Cwtch nunca deve ser capaz de distinguir mensagens como pertencentes a um grupo específico. Observamos aqui que essas propriedades são um superconjunto dos objetivos de design das estruturas de Recuperação de Informações Privadas.

Melhorias na Eficiência e Segurança

Eficiência do Protocolo

Atualmente, apenas um protocolo conhecido, o PIR ingênuo, atende às propriedades desejadas para garantir a privacidade na comunicação do grupo Cwtch. Este método tem um impacto direto na eficiência da largura de banda, especialmente para usuários em dispositivos móveis. Em resposta a isso, estamos ativamente desenvolvendo novos protocolos que permitem negociar garantias de privacidade e eficiência de maneiras diversas.

Os servidores, no momento desta escrita, permitem o download completo de todas as mensagens armazenadas, bem como uma solicitação para baixar mensagens específicas a partir de uma determinada mensagem. Quando os pares ingressam em um grupo em um novo servidor, eles baixam todas as mensagens do servidor inicialmente e, posteriormente, apenas as mensagens novas.

Mitigação de Análise de Metadados

Essa abordagem permite uma análise moderada de metadados, pois o servidor pode enviar novas mensagens para cada perfil suspeito exclusivo e usar essas assinaturas de mensagens exclusivas para rastrear sessões ao longo do tempo. Essa preocupação é mitigada por dois fatores:

1. Os perfis podem atualizar suas conexões a qualquer momento, resultando em uma nova sessão do servidor.
2. Os perfis podem ser "ressincronizados" de um servidor a qualquer momento, resultando em uma nova chamada para baixar todas as mensagens. Isso é comumente usado para buscar mensagens antigas de um grupo.

Embora essas medidas imponham limites ao que o servidor pode inferir, ainda não podemos garantir resistência total aos metadados. Para soluções futuras para esse problema, consulte Niwl.

Proteção contra Pares Maliciosos

Os servidores enfrentam o risco de spam gerado por pares, representando uma ameaça significativa à eficácia do sistema Cwtch. Embora tenhamos implementado um mecanismo de proteção contra spam no protótipo do Cwtch, exigindo que os pares realizem alguma prova de trabalho especificada pelo servidor, reconhecemos que essa não é uma solução robusta na presença de um adversário determinado com recursos significativos.

Pacotes de Chaves

Os servidores Cwtch se identificam por meio de pacotes de chaves assinados, contendo uma lista de chaves necessárias para garantir a segurança e resistência aos metadados na comunicação do grupo Cwtch. Esses pacotes de chaves geralmente incluem três chaves: uma chave pública do serviço Tor v3 Onion para o Token Board, uma chave pública do Tor v3 Onion Service para o Token Service e uma chave pública do Privacy Pass.

Para verificar os pacotes de chaves, os perfis que os importam do servidor utilizam o algoritmo trust-on-first-use (TOFU), verificando a assinatura anexada e a existência de todos os tipos de chave. Se o perfil já tiver importado o pacote de chaves do servidor anteriormente, todas as chaves são consideradas iguais.

Configuração prévia do aplicativo para ativar o Relé do Cwtch.

No Android, a hospedagem de servidor não está habilitada, pois essa opção não está disponível devido às limitações dos dispositivos Android. Essa funcionalidade está reservada apenas para servidores hospedados em desktops.

No Android, a única forma direta de importar uma chave de servidor é através do grupo de teste Cwtch, garantindo assim acesso ao servidor Cwtch.

Primeiro passo é Habilitar a opção de grupo no Cwtch que está em fase de testes. Clique na opção no canto superior direito da tela de configuração e pressione o botão para acessar as configurações do Cwtch.

Você pode alterar o idioma para Português do Brasil.Depois, role para baixo e selecione a opção para ativar os experimentos. Em seguida, ative a opção para habilitar o chat em grupo e a pré-visualização de imagens e fotos de perfil, permitindo que você troque sua foto de perfil.

https://link.storjshare.io/raw/jvss6zxle26jdguwaegtjdixhfka/production/f0ca039733d48895001261ab25c5d2efbaf3bf26e55aad3cce406646f9af9d15.MP4

Próximo passo é Criar um perfil.

Pressione o + botão de ação no canto inferior direito e selecione "Novo perfil" ou aberta no botão + adicionar novo perfil.

• Selecione um nome de exibição

• Selecione se deseja proteger

este perfil e salvo localmente com criptografia forte: Senha: sua conta está protegida de outras pessoas que possam usar este dispositivo

Sem senha: qualquer pessoa que tenha acesso a este dispositivo poderá acessar este perfil.

Preencha sua senha e digite-a novamente

Os perfis são armazenados localmente no disco e criptografados usando uma chave derivada de uma senha conhecida pelo usuário (via pbkdf2).

Observe que, uma vez criptografado e armazenado em disco, a única maneira de recuperar um perfil é recuperando a chave da senha - como tal, não é possível fornecer uma lista completa de perfis aos quais um usuário pode ter acesso até inserir um senha.

https://link.storjshare.io/raw/jxqbqmur2lcqe2eym5thgz4so2ya/production/8f9df1372ec7e659180609afa48be22b12109ae5e1eda9ef1dc05c1325652507.MP4

O próximo passo é adicionar o FuzzBot, que é um bot de testes e de desenvolvimento.

Contato do FuzzBot: 4y2hxlxqzautabituedksnh2ulcgm2coqbure6wvfpg4gi2ci25ta5ad.

Ao enviar o comando "testgroup-invite" para o FuzzBot, você receberá um convite para entrar no Grupo Cwtch Test. Ao ingressar no grupo, você será automaticamente conectado ao servidor Cwtch. Você pode optar por sair do grupo a qualquer momento ou ficar para conversar e tirar dúvidas sobre o aplicativo e outros assuntos. Depois, você pode configurar seu próprio servidor Cwtch, o que é altamente recomendável.

https://link.storjshare.io/raw/jvji25zclkoqcouni5decle7if7a/production/ee3de3540a3e3dca6e6e26d303e12c2ef892a5d7769029275b8b95ffc7468780.MP4

Agora você pode utilizar o aplicativo normalmente. Algumas observações que notei: se houver demora na conexão com outra pessoa, ambas devem estar online. Se ainda assim a conexão não for estabelecida, basta clicar no ícone de reset do Tor para restabelecer a conexão com a outra pessoa.

Uma introdução aos perfis Cwtch.

Com Cwtch você pode criar um ou mais perfis . Cada perfil gera um par de chaves ed25519 aleatório compatível com a Rede Tor.

Este é o identificador que você pode fornecer às pessoas e que elas podem usar para entrar em contato com você via Cwtch.

Cwtch permite criar e gerenciar vários perfis separados. Cada perfil está associado a um par de chaves diferente que inicia um serviço cebola diferente.

Gerenciar Na inicialização, o Cwtch abrirá a tela Gerenciar Perfis. Nessa tela você pode:

• Crie um novo perfil.
• Desbloquear perfis.
• Criptografados existentes.
• Gerenciar perfis carregados.
• Alterando o nome de exibição de um perfil.
• Alterando a senha de um perfil Excluindo um perfil.
• Alterando uma imagem de perfil.

Backup ou exportação de um perfil.

Na tela de gerenciamento de perfil:

1. Selecione o lápis ao lado do perfil que você deseja editar

2. Role para baixo até a parte inferior da tela.

3. Selecione "Exportar perfil"

4. Escolha um local e um nome de arquivo.

5.confirme.

Uma vez confirmado, o Cwtch colocará uma cópia do perfil no local indicado. Este arquivo é criptografado no mesmo nível do perfil.

Este arquivo pode ser importado para outra instância do Cwtch em qualquer dispositivo.

Importando um perfil.

1. Pressione o +botão de ação no canto inferior direito e selecione "Importar perfil"

2. Selecione um arquivo de perfil Cwtch exportado para importar

3. Digite a senha associada ao perfil e confirme.

Uma vez confirmado, o Cwtch tentará descriptografar o arquivo fornecido usando uma chave derivada da senha fornecida. Se for bem-sucedido, o perfil aparecerá na tela Gerenciamento de perfil e estará pronto para uso.

OBSERVAÇÃO Embora um perfil possa ser importado para vários dispositivos, atualmente apenas uma versão de um perfil pode ser usada em todos os dispositivos ao mesmo tempo. As tentativas de usar o mesmo perfil em vários dispositivos podem resultar em problemas de disponibilidade e falhas de mensagens.

Qual é a diferença entre uma conexão ponto a ponto e um grupo cwtch?

As conexões ponto a ponto Cwtch permitem que 2 pessoas troquem mensagens diretamente. As conexões ponto a ponto nos bastidores usam serviços cebola Tor v3 para fornecer uma conexão criptografada e resistente a metadados. Devido a esta conexão direta, ambas as partes precisam estar online ao mesmo tempo para trocar mensagens.

Os Grupos Cwtch permitem que várias partes participem de uma única conversa usando um servidor não confiável (que pode ser fornecido por terceiros ou auto-hospedado). Os operadores de servidores não conseguem saber quantas pessoas estão em um grupo ou o que está sendo discutido. Se vários grupos estiverem hospedados em um único servidor, o servidor não conseguirá saber quais mensagens pertencem a qual grupo sem a conivência de um membro do grupo. Ao contrário das conversas entre pares, as conversas em grupo podem ser conduzidas de forma assíncrona, para que todos num grupo não precisem estar online ao mesmo tempo.

Por que os grupos cwtch são experimentais? Mensagens em grupo resistentes a metadados ainda são um problema em aberto . Embora a versão que fornecemos no Cwtch Beta seja projetada para ser segura e com metadados privados, ela é bastante ineficiente e pode ser mal utilizada. Como tal, aconselhamos cautela ao usá-lo e apenas o fornecemos como um recurso opcional.

Como posso executar meu próprio servidor Cwtch? A implementação de referência para um servidor Cwtch é de código aberto . Qualquer pessoa pode executar um servidor Cwtch, e qualquer pessoa com uma cópia do pacote de chaves públicas do servidor pode hospedar grupos nesse servidor sem que o operador tenha acesso aos metadados relacionados ao grupo .

https://git.openprivacy.ca/cwtch.im/server

https://docs.openprivacy.ca/cwtch-security-handbook/server.html

Como posso desligar o Cwtch? O painel frontal do aplicativo possui um ícone do botão "Shutdown Cwtch" (com um 'X'). Pressionar este botão irá acionar uma caixa de diálogo e, na confirmação, o Cwtch será desligado e todos os perfis serão descarregados.

Suas doações podem fazer a diferença no projeto Cwtch? O Cwtch é um projeto dedicado a construir aplicativos que preservam a privacidade, oferecendo comunicação de grupo resistente a metadados. Além disso, o projeto também desenvolve o Cofre, formulários da web criptografados para ajudar mútua segura. Suas contribuições apoiam iniciativas importantes, como a divulgação de violações de dados médicos em Vancouver e pesquisas sobre a segurança do voto eletrônico na Suíça. Ao doar, você está ajudando a fechar o ciclo, trabalhando com comunidades marginalizadas para identificar e corrigir lacunas de privacidade. Além disso, o projeto trabalha em soluções inovadoras, como a quebra de segredos através da criptografia de limite para proteger sua privacidade durante passagens de fronteira. E também tem a infraestrutura: toda nossa infraestrutura é open source e sem fins lucrativos. Conheça também o Fuzzytags, uma estrutura criptográfica probabilística para marcação resistente a metadados. Sua doação é crucial para continuar o trabalho em prol da privacidade e segurança online. Contribua agora com sua doação

https://openprivacy.ca/donate/

onde você pode fazer sua doação em bitcoin e outras moedas, e saiba mais sobre os projetos. https://openprivacy.ca/work/

Link sobre Cwtch

https://cwtch.im/

https://git.openprivacy.ca/cwtch.im/cwtch

https://docs.cwtch.im/docs/intro

https://docs.openprivacy.ca/cwtch-security-handbook/

Baixar #CwtchDev

cwtch.im/download/

https://play.google.com/store/apps/details?id=im.cwtch.flwtch

@ 7e538978:a5987ab6

Chain Duel, a fast paced PvP game that takes inspiration from the classic snake game and supercharges it with Bitcoin’s Lightning Network. Imagine battling another player for dominance in a race to collect blocks, where the length of your chain isn’t just a visual cue. It represents real, staked satoshis. The player with the most Proof of Work wins, but it’s not just about gameplay; it’s about the seamless integration of the Lightning Network and real-time payments.

But how does Chain Duel manage these instant transactions with such efficiency? That’s where LNbits comes in. LNbits, an open-source wallet and payment infrastructure, handles all in-game payments making it easy for developers to focus on gameplay while LNbits takes care of everything from microtransactions to automated splits for developers and designers. In this article, we’ll dive deep into how Chain Duel leverages LNbits to streamline in-game payments and how other developers can take advantage of this powerful toolset to build the future of Lightning-powered gaming.

Let’s explore how LNbits transforms payment processing and why it’s quickly becoming a must-have for game developers working in the Bitcoin space.

Overview of Chain Duel

Chain Duel is a unique Lightning Network-inspired game that reimagines the classic snake game with a competitive twist, integrating real-time payments. Two players face off in real-time, racing to "catch" blocks and extend their chains. Each block added to the chain represents Proof of Work, and the player with the most Proof of Work wins the duel. The stakes are high, as the game represents satoshis (small units of Bitcoin) as points, with the winner taking home the prize.

The game is designed to be Lightning-native, meaning all payments within Chain Duel are processed through the Lightning Network. This ensures fast payments, reducing latency and making gameplay smooth. With additional features like practice mode, tournaments and highscores, Chain Duel creates an engaging and competitive environment for Bitcoin enthusiasts and gamers alike.

One of the standout aspects of Chain Duel is its deeper integration with the Lightning Network even at a design level. For example, actual Bitcoin blocks can appear on screen during matches, offering bonus points when mined in sync with the game. The game’s current version, still in beta, has already drawn attention within the Bitcoin community, gaining momentum at conferences and with a growing user base through its social networks. With its innovative combination of gaming, the Lightning Network, and competitive play, Chain Duel offers a glimpse into the future of Lightning-based gaming.

How LNbits is Used in Chain Duel

Seamless Integration with LNbits

At the core of Chain Duel’s efficient payment processing is LNbits, which handles in-game transactions smoothly and reliably. Chain Duel uses the LNbits LNURL-pay and LNURL-withdraw extensions to manage payments and rewards between players. Before each match, players send satoshis using LNURL-pay, which generates a static QR code or link for making the payment. LNURL-pay allows users to attach a note to the payment, which Chain Duel creatively uses as a way to insert the player name in-game. The simplicity of LNURL-pay ensures that users can quickly and easily initiate games, with fresh invoices being issued for every game. When players win, LNURL-withdraw enables them to seamlessly pull their earnings from the game, providing a quick payout system.

These extensions make it easy for players to send and receive Bitcoin with minimal latency, fully leveraging the power of the Lightning Network for fast and low-cost payments. The flexibility of LNbits’ tools means that game developers don’t need to worry about building custom payment systems from scratch—they can rely on LNbits to handle all financial transactions with precision.

Lightning Tournaments

Chain Duel tournaments leverage LNbits and its LNURL extensions to create a seamless and efficient experience for players. In Chain Duel tournaments, LNbits plays a crucial role in managing the overall economics. LNbits facilitates the generation of LNURL QR codes that participants can scan to register quickly or withdraw their winnings. LNbits allows Chain Duel to automatically handle multiple registrations through LNURL-pay, enabling players to participate in the tournament without additional steps. The Lightning Network's speed ensures that these payments occur in real-time, reducing wait times and allowing for a smoother flow in-game.

Splitting Payments

LNbits further simplifies revenue-sharing within Chain Duel. This feature allows the game to automatically split the satoshis sent by players into different shares for the game’s developer, designer, and host. Each time a payment is made to join a match, LNbits is used to automattically pay each of the contributors, according to pre-defined rules. This automated process ensures that everyone involved in the development and running of the game gets their fair share without manual intervention or complex bookkeeping.

Nostr Integration

Chain Duel also integrates with Nostr, a decentralized protocol for social interactions. Players can join games using "Zaps", small tips or micropayments sent over the Lightning Network within the Nostr ecosystem. Through NIP-57, which enables Nostr clients to request Zap invoices, players can use LNURL-pay enabled Zaps to register in P2P matches, further enhancing the Chain Duel experience. By using Zaps as a way to register in-game, Chain Duel automates the process of fetching players' identity, creating a more competitive and social experience. Zaps are public on the Nostr network, further expanding Chain Duel's games social reach and community engagement.

Game and Payment Synchronization

One of the key reasons Chain Duel developers chose LNbits is its powerful API that connects directly with the game’s logic. LNbits allows the game to synchronize payments with gameplay in real-time, providing a seamless experience where payments are an integrated part of the gaming mechanics.

With LNbits managing both the payment process and the Lightning Network’s complex infrastructure, Chain Duel developers are free to concentrate on enhancing the competitive and Lightning Network-related aspects of the game. This division of tasks is essential for streamlining development while still providing an innovative in-game payment experience that is deeply integrated with the Bitcoin network.

LNbits proves to be an indispensable tool for Chain Duel, enabling smooth in-game transactions, real-time revenue sharing, and seamless integration with Nostr. For developers looking to build Lightning-powered games, LNbits offers a powerful suite of tools that handle everything from micropayments to payment distribution—ensuring that the game's focus remains on fun and competition rather than complex payment systems.

LNBits facilitating Education and Adoption

This system contributes to educating users on the power of the Lightning Network. Since Chain Duel directly involve real satoshis and LNURL for registration and rewards, players actively experience how Lightning can facilitate fast, cheap, and permissionless payments. By incorporating LNbits into Chain Duel, the game serves as an educational tool that introduces users to the benefits of the Lightning Network. Players gain direct experience using Lightning wallets and LNURL, helping them understand how these tools work in real-world scenarios. The near-instant nature of these payments showcases the power of Lightning in a practical context, highlighting its potential beyond just gaming. Players are encouraged to set up wallets, explore the Lightning ecosystem, and eventually become familiar with Bitcoin and Lightning technology. By integrating LNbits, Chain Duel transforms in-game payments into a learning opportunity, making Bitcoin and Lightning more approachable for users worldwide.

Tools for Developers

LNbits is a versatile, open-source platform designed to simplify and enhance Bitcoin Lightning Network wallet management. For developers, particularly those working on Lightning-native games like Chain Duel, LNbits offers an invaluable set of tools that allow for seamless integration of Lightning payments without the need to build complex custom solutions from scratch. LNbits is built on a modular and extensible architecture, enabling developers to easily add or create functionality suited to their project’s needs.

Extensible Architecture for Customization

At the core of LNbits is a simple yet powerful wallet system that developers can access across multiple devices. What makes LNbits stand out is its extensible nature—everything beyond the core functionality is implemented as an extension. This modular approach allows users to customize their LNbits installation by enabling or building extensions to suit specific use cases. This flexibility is perfect for developers who want to add Lightning-based services to their games or apps without modifying the core codebase.

• Extensions for Every Use Case
  LNbits comes with a wide array of built-in extensions created by contributors, offering various services that can be plugged into your application. Some popular extensions include:
• Faucets: Distribute small amounts of Bitcoin to users for testing or promotional purposes.
• Paylinks: Create shareable links for instant payments.
• Points-of-sale (PoS): Allow users to set up shareable payment terminals.
• Paywalls: Charge users to access content or services.
• Event tickets: Sell tickets for events directly via Lightning payments.
• Games and services: From dice games to jukeboxes, LNbits offers entertaining and functional tools.

These ready-made solutions can be adapted and used in different gaming scenarios, for example in Chain Duel, where LNURL extensions are used for in game payments. The extensibility ensures developers can focus on building engaging gameplay while LNbits handles payment flows.

Developer-Friendly Customization

LNbits isn't just a plug-and-play platform. Developers can extend its functionality even further by creating their own extensions, giving full control over how the wallet system is integrated into their games or apps. The architecture is designed to make it easy for developers to build on top of the platform, adding custom features for specific requirements.

Flexible Funding Source Management

LNbits also offers flexibility in terms of managing funding sources. Developers can easily connect LNbits to various Lightning Network node implementations, enabling seamless transitions between nodes or even different payment systems. This allows developers to switch underlying funding sources with minimal effort, making LNbits adaptable for games that may need to scale quickly or rely on different payment infrastructures over time.

A Lean Core System for Maximum Efficiency

Thanks to its modular architecture, LNbits maintains a lean core system. This reduces complexity and overhead, allowing developers to implement only the features they need. By avoiding bloated software, LNbits ensures faster transactions and less resource consumption, which is crucial in fast-paced environments like Chain Duel where speed and efficiency are paramount.

LNbits is designed with developers in mind, offering a suite of tools and a flexible infrastructure that makes integrating Bitcoin payments easy. Whether you’re developing games, apps, or any service that requires Lightning Network transactions, LNbits is a powerful, open-source solution that can be adapted to fit your project.

Conclusion

Chain Duel stands at the forefront of Lightning-powered gaming, combining the excitement of competitive PvP with the speed and efficiency of the Lightning Network. With LNbits handling all in-game payments, from microtransactions to automated revenue splits, developers can focus entirely on crafting an engaging gaming experience. LNbits’ powerful API and extensions make it easy to manage real-time payments, removing the complexity of building payment infrastructure from scratch.

LNbits isn’t just a payment tool — it’s a flexible, developer-friendly platform that can be adapted to any gaming model. Whether you're developing a fast-paced PvP game like Chain Duel or any project requiring seamless Lightning Network integration, LNbits provides the ideal solution for handling instant payments with minimal overhead.

For developers interested in pushing the boundaries of Lightning-powered gaming, Chain Duel is a great example of how LNbits can enhance your game, letting you focus on the fun while LNbits manages real-time transactions.

Find out more

Curious about how Lightning Network payments can power your next game? Explore the following:

• Learn more about Chain Duel: Chain Duel
• Learn how LNbits can simplify payment handling in your project: LNbits
• Dive into decentralized communication with Nostr: Nostr

@ c4f5e7a7:8856cac7

Best viewed on Habla, YakiHonne or Highlighter.

TL;DR

This article explores the links between public, community-driven data sources (such as OpenStreetMap) and private, cryptographically-owned data found on networks such as Nostr.

The following concepts are explored:

1. Attestations: Users signalling to their social graph that they believe something to be true by publishing Attestations. These social proofs act as a decentralised verification system that leverages your web-of-trust.
2. Proof of Place: An oracle-based system where physical letters are sent to real-world locations, confirming the corresponding digital ownership via cryptographic proofs. This binds physical locations in meatspace with their digital representations in the Nostrverse.
3. Check-ins: Foursquare-style check-ins that can be verified using attestations from place owners, ensuring authenticity. This approach uses web-of-trust to validate check-ins and location ownership over time.

The goal is to leverage cryptographic ownership where necessary while preserving the open, collaborative nature of public data systems.

Open Data in a public commons has a place and should not be thrown out with the Web 2.0 bathwater.

Cognitive Dissonance

Ever since discovering Nostr in August of 2022 I've been grappling with how BTC Map - a project that helps bitcoiners find places to spend sats - should most appropriately use this new protocol.

I am assuming, dear reader, that you are somewhat familiar with Nostr - a relatively new protocol for decentralised identity and communication. If you don’t know your nsec from your npub, please take some time to read these excellent posts: Nostr is Identity for the Internet and The Power of Nostr by @max and @lyn, respectively. Nostr is so much more than a short-form social media replacement.

The social features (check-ins, reviews, etc.) that Nostr unlocks for BTC Map are clear and exciting - all your silos are indeed broken - however, something fundamental has been bothering me for a while and I think it comes down to data ownership.

For those unfamiliar, BTC Map uses OpenStreetMap (OSM) as its main geographic database. OSM is centred on the concept of a commons of objectively verifiable data that is maintained by a global community of volunteer editors; a Wikipedia for maps. There is no data ownership; the data is free (as in freedom) and anyone can edit anything. It is the data equivalent of FOSS (Free and Open Source Software) - FOSD if you will, but more commonly referred to as Open Data.

In contrast, Notes and Other Stuff on Nostr (Places in this cartographic context) are explicitly owned by the controller of the private key. These notes are free to propagate, but they are owned.

How do we reconcile the decentralised nature of Nostr, where data is cryptographically owned by individuals, with the community-managed data commons of OpenStreetMap, where no one owns the data?

Self-sovereign Identity

Before I address this coexistence question, I want to talk a little about identity as it pertains to ownership. If something is to be owned, it has to be owned by someone or something - an identity.

All identities that are not self-sovereign are, by definition, leased to you by a 3rd party. You rent your Facebook identity from Meta in exchange for your data. You rent your web domain from your DNS provider in exchange for your money.

Taken to the extreme, you rent your passport from your Government in exchange for your compliance. You are you at the pleasure of others. Where Bitcoin separates money from the state; Nostr separates identity from the state.

Or, as @nvk said recently: "Don't build your house on someone else's land.".

https://i.nostr.build/xpcCSkDg3uVw0yku.png

While we’ve had the tools for self-sovereign digital identity for decades (think PGP keys or WebAuthN), we haven't had the necessary social use cases nor the corresponding social graph to elevate these identities to the mainstream. Nostr fixes this.

Nostr is PGP for the masses and will take cryptographic identities mainstream.

Full NOSTARD?

Returning to the coexistence question: the data on OpenStreetMap isn’t directly owned by anyone, even though the physical entities the data represents might be privately owned. OSM is a data commons.

We can objectively agree on the location of a tree or a fire hydrant without needing permission to observe and record it. Sure, you could place a tree ‘on Nostr’, but why should you? Just because something can be ‘on Nostr’ doesn’t mean it should be.

https://i.nostr.build/s3So2JVAqoY4E1dI.png

There might be a dystopian future where we can't agree on what a tree is nor where it's located, but I hope we never get there. It's at this point we'll need a Wikifreedia variant of OpenStreetMap.

While integrating Nostr identities into OpenStreetMap would be valuable, the current OSM infrastructure, tools, and community already provide substantial benefits in managing this data commons without needing to go NOSTR-native - there's no need to go Full NOSTARD. H/T to @princeySOV for the original meme.

https://i.nostr.build/ot9jtM5cZtDHNKWc.png

So, how do we appropriately blend cryptographically owned data with the commons?

If a location is owned in meatspace and it's useful to signal that ownership, it should also be owned in cyberspace. Our efforts should therefore focus on entities like businesses, while allowing the commons to manage public data for as long as it can successfully mitigate the tragedy of the commons.

The remainder of this article explores how we can:

1. Verify ownership of a physical place in the real world;
2. Link that ownership to the corresponding digital place in cyberspace.

As a side note, I don't see private key custodianship - or, even worse, permissioned use of Places signed by another identity's key - as any more viable than the rented identities of Web 2.0.

And as we all know, the Second Law of Infodynamics (no citation!) states that:

"The total amount of sensitive information leaked will always increase over time."

This especially holds true if that data is centralised.

Not your keys, not your notes. Not your keys, not your identity.

Places and Web-of-Trust

@Arkinox has been leading the charge on the Places NIP, introducing Nostr notes (kind 37515) that represent physical locations. The draft is well-crafted, with bonus points for linking back to OSM (and other location repositories) via NIP-73 - External Content IDs (championed by @oscar of @fountain).

However, as Nostr is permissionless, authenticity poses a challenge. Just because someone claims to own a physical location on the Internet doesn’t necessarily mean they have ownership or control of that location in the real world.

Ultimately, this problem can only be solved in a decentralised way by using Web-of-Trust - using your social graph and the perspectives of trusted peers to inform your own perspective. In the context of Places, this requires your network to form a view on which digital identity (public key / npub) is truly the owner of a physical place like your local coffee shop.

This requires users to:

1. Verify the owner of a Place in cyberspace is the owner of a place in meatspace.
2. Signal this verification to their social graph.

Let's look at the latter idea first with the concept of Attestations ...

Attestations

A way to signal to your social graph that you believe something to be true (or false for that matter) would be by publishing an Attestation note. An Attestation note would signify to your social graph that you think something is either true or false.

Imagine you're a regular at a local coffee shop. You publish an Attestation that says the shop is real and the owner behind the Nostr public key is who they claim to be. Your friends trust you, so they start trusting the shop's digital identity too.

However, attestations applied to Places are just a single use case. The attestation concept could be more widely applied across Nostr in a variety of ways (key rotation, identity linking, etc).

Here is a recent example from @lyn that would carry more signal if it were an Attestation:

https://i.nostr.build/lZAXOEwvRIghgFY4.png

Parallels can be drawn between Attestations and transaction confirmations on the Bitcoin timechain; however, their importance to you would be weighted by clients and/or Data Vending Machines in accordance with:

1. Your social graph;
2. The type or subject of the content being attested and by whom;
3. Your personal preferences.

They could also have a validity duration to be temporally bound, which would be particularly useful in the case of Places.

NIP-25 (Reactions) do allow for users to up/downvote notes with optional content (e.g., emojis) and could work for Attestations, but I think we need something less ambiguous and more definitive.

‘This is true’ resonates more strongly than ‘I like this.’.

https://i.nostr.build/s8NIG2kXzUCLcoax.jpg

There are similar concepts in the Web 3 / Web 5 world such as Verified Credentials by tdb. However, Nostr is the Web 3 now and so wen Attestation NIP?

https://i.nostr.build/Cb047NWyHdJ7h5Ka.jpg

That said, I have seen @utxo has been exploring ‘smart contracts’ on nostr and Attestations may just be a relatively ‘dumb’ subset of the wider concept Nostr-native scripting combined with web-of-trust.

Proof of Place

Attestations handle the signalling of your truth, but what about the initial verification itself?

We already covered how this ultimately has to be derived from your social graph, but what if there was a way to help bootstrap this web-of-trust through the use of oracles? For those unfamiliar with oracles in the digital realm, they are simply trusted purveyors of truth.

Introducing Proof of Place, an out–of-band process where an oracle (such as BTC Map) would mail - yes physically mail- a shared secret to the address of the location being claimed in cyberspace. This shared secret would be locked to the public key (npub) making the claim, which, if unlocked, would prove that the associated private key (nsec) has physical access to the location in meatspace.

One way of doing this would be to mint a 1 sat cashu ecash token locked to the npub of the claimant and mail it to them. If they are able to redeem the token then they have cryptographically proven that they have physical access to the location.

Proof of Place is really nothing more than a weighted Attestation. In a web-of-trust Nostrverse, an oracle is simply a npub (say BTC Map) that you weigh heavily for its opinion on a given topic (say Places).

In the Bitcoin world, Proof of Work anchors digital scarcity in cyberspace to physical scarcity (energy and time) in meatspace and as @Gigi says in PoW is Essential:

"A failure to understand Proof of Work, is a failure to understand Bitcoin."

In the Nostrverse, Proof of Place helps bridge the digital and physical worlds.

@Gigi also observes in Memes vs The World that:

"In Bitcoin, the map is the territory. We can infer everything we care about by looking at the map alone."

https://i.nostr.build/dOnpxfI4u7EL2v4e.png

This isn’t true for Nostr.

In the Nostrverse, the map IS NOT the territory. However, Proof of Place enables us to send cryptographic drones down into the physical territory to help us interpret our digital maps. 🤯

Check-ins

Although not a draft NIP yet, @Arkinox has also been exploring the familiar concept of Foursquare-style Check-ins on Nostr (with kind 13811 notes).

For the uninitiated, Check-ins are simply notes that signal the publisher is at a given location. These locations could be Places (in the Nostr sense) or any other given digital representation of a location for that matter (such as OSM elements) if NIP-73 - External Content IDs are used.

Of course, not everyone will be a Check-in enjoyooor as the concept will not sit well with some people’s threat models and OpSec practices.

Bringing Check-ins to Nostr is possible (as @sebastix capably shows here), but they suffer the same authenticity issues as Places. Just because I say I'm at a given location doesn't mean that I am.

Back in the Web 2.0 days, Foursquare mitigated this by relying on the GPS position of the phone running their app, but this is of course spoofable.

How should we approach Check-in verifiability in the Nostrverse? Well, just like with Places, we can use Attestations and WoT. In the context of Check-ins, an Attestation from the identity (npub) of the Place being checked-in to would be a particularly strong signal. An NFC device could be placed in a coffee shop and attest to check-ins without requiring the owner to manually intervene - I’m sure @blackcoffee and @Ben Arc could hack something together over a weekend!

Check-ins could also be used as a signal for bonafide Place ownership over time.

Summary: Trust Your Bros

So, to recap, we have:

Places: Digital representations of physical locations on Nostr.

Check-ins: Users signalling their presence at a location.

Attestations: Verifiable social proofs used to confirm ownership or the truth of a claim.

You can visualise how these three concepts combine in the diagram below:

https://i.nostr.build/Uv2Jhx5BBfA51y0K.jpg

And, as always, top right trumps bottom left! We have:

Level 0 - Trust Me Bro: Anyone can check-in anywhere. The Place might not exist or might be impersonating the real place in meatspace. The person behind the npub may not have even been there at all.

Level 1 - Definitely Maybe Somewhere: This category covers the middle-ground of ‘Maybe at a Place’ and ‘Definitely Somewhere’. In these examples, you are either self-certifying that you have checked-in at an Attested Place or you are having others attest that you have checked-in at a Place that might not even exist IRL.

Level 2 - Trust Your Bros: An Attested Check-in at an Attested Place. Your individual level of trust would be a function of the number of Attestations and how you weigh them within your own social graph.

https://i.nostr.build/HtLAiJH1uQSTmdxf.jpg

Perhaps the gold standard (or should that be the Bitcoin standard?) would be a Check-in attested by the owner of the Place, which in itself was attested by BTC Map?

Or perhaps not. Ultimately, it’s the users responsibility to determine what they trust by forming their own perspective within the Nostrverse powered by web-of-trust algorithms they control. ‘Trust Me Bro’ or ‘Trust Your Bros’ - you decide.

As we navigate the frontier of cryptographic ownership and decentralised data, it’s up to us to find the balance between preserving the Open Data commons and embracing self-sovereign digital identities.

Thanks

With thanks to Arkinox, Avi, Ben Gunn, Kieran, Blackcoffee, Sebastix, Tomek, Calle, Short Fiat, Ben Weeks and Bitcoms for helping shape my thoughts and refine content, whether you know it or not!

@ f977c464:32fcbe00

Güneşin kaybolmasının üçüncü günü, saat öğlen on ikiyi yirmi geçiyordu. Trenin kalkmasına yaklaşık iki saat vardı. Hepimiz perondaydık. Valizlerimiz, kolilerimiz, renk renk ve biçimsiz çantalarımızla yan yana dizilmiş, kısa aralıklarla tepemizdeki devasa saati kontrol ediyorduk.

Ama ne kadar dik bakarsak bakalım zaman bir türlü istediğimiz hızla ilerlemiyordu. Herkes birkaç dakika sürmesi gereken alelade bir doğa olayına sıkışıp kalmış, karanlıktan sürünerek çıkmayı deniyordu.

Bekleme salonuna doğru döndüm. Nefesimden çıkan buharın arkasında, kalın taş duvarları ve camlarıyla morg kadar güvenli ve soğuk duruyordu. Cesetleri o yüzden bunun gibi yerlere taşımaya başlamışlardı. Demek insanların bütün iyiliği başkaları onları gördüğü içindi ki gündüzleri gecelerden daha karanlık olduğunda hemen birbirlerinin gırtlağına çökmüş, böğürlerinde delikler açmış, gözlerini oyup kafataslarını parçalamışlardı.

İstasyonun ışığı titrediğinde karanlığın enseme saplandığını hissettim. Eğer şimdi, böyle kalabalık bir yerde elektrik kesilse başımıza ne gelirdi?

İçerideki askerlerden biri bakışlarımı yakalayınca yeniden saate odaklanmış gibi yaptım. Sadece birkaç dakika geçmişti.

“Tarlalarım gitti. Böyle boyum kadar ayçiçeği doluydu. Ah, hepsi ölüp gidiyor. Afitap’ın çiçekleri de gi-”

“Dayı, Allah’ını seversen sus. Hepimizi yakacaksın şimdi.”

Karanlıkta durduğunda, görünmez olmayı istemeye başlıyordun. Kimse seni görmemeli, nefesini bile duymamalıydı. Kimsenin de ayağının altında dolaşmamalıydın; gelip kazayla sana çarpmamalılar, takılıp sendelememeliydiler. Yoksa aslında hedefi sen olmadığın bir öfke gürlemeye başlar, yaşadığın ilk şoku ve acıyı silerek üstünden geçerdi.

İlk konuşan, yaşlıca bir adam, kafasında kasketi, nasırlı ellerine hohluyordu. Gözleri ve burnu kızarmıştı. Güneşin kaybolması onun için kendi başına bir felaket değildi. Hayatına olan pratik yansımalarından korkuyordu olsa olsa. Bir anının kaybolması, bu yüzden çoktan kaybettiği birinin biraz daha eksilmesi. Hayatta kalmasını gerektiren sebepler azalırken, hayatta kalmasını sağlayacak kaynaklarını da kaybediyordu.

Onu susturan delikanlıysa atkısını bütün kafasına sarmış, sakalı ve yüzünün derinliklerine kaçmış gözleri dışında bedeninin bütün parçalarını gizlemeye çalışıyordu. İşte o, güneşin kaybolmasının tam olarak ne anlama geldiğini anlamamış olsa bile, dehşetini olduğu gibi hissedebilenlerdendi.

Güneşin onlardan alındıktan sonra kime verileceğini sormuyorlardı. En başta onlara verildiğinde de hiçbir soru sormamışlardı zaten.

İki saat ne zaman geçer?

Midemin üstünde, sağ tarafıma doğru keskin bir acı hissettim. Karaciğerim. Gözlerimi yumdum. Yanımda biri metal bir nesneyi yere bıraktı. Bir kafesti. İçerisindeki kartalın ıslak kokusu burnuma ulaşmadan önce bile biliyordum bunu.

“Yeniden mi?” diye sordu bana kartal. Kanatları kanlı. Zamanın her bir parçası tüylerinin üstüne çöreklenmişti. Gagası bir şey, tahminen et parçası geveliyor gibi hareket ediyordu. Eski anılar kolay unutulmazmış. Şu anda kafesinin kalın parmaklıklarının ardında olsa da bunun bir aldatmaca olduğunu bir tek ben biliyordum. Her an kanatlarını iki yana uzatıverebilir, hava bu hareketiyle dalgalanarak kafesi esneterek hepimizi içine alacak kadar genişleyebilir, parmaklıklar önce ayaklarımızın altına serilir gibi gözükebilir ama aslında hepimizin üstünde yükselerek tepemize çökebilirdi.

Aşağıya baktım. Tahtalarla zapt edilmiş, hiçbir yere gidemeyen ama her yere uzanan tren rayları. Atlayıp koşsam… Çantam çok ağırdı. Daha birkaç adım atamadan, kartal, suratını bedenime gömerdi.

“Bu sefer farklı,” diye yanıtladım onu. “Yeniden diyemezsin. Tekrarladığım bir şey değil bu. Hatta bir hata yapıyormuşum gibi tonlayamazsın da. Bu sefer, insanların hak etmediğini biliyorum.”

“O zaman daha vahim. Süzme salaksın demektir.”

“İnsanların hak etmemesi, insanlığın hak etmediği anlamına gelmez ki.”

Az önce göz göze geldiğim genççe ama çökük asker hâlâ bana bakıyordu. Bir kartalla konuştuğumu anlamamıştı şüphesiz. Yanımdakilerden biriyle konuştuğumu sanmış olmalıydı. Ama konuştuğum kişiye bakmıyordum ona göre. Çekingence kafamı eğmiştim. Bir kez daha göz göze geldiğimizde içerideki diğer iki askere bir şeyler söyledi, onlar dönüp beni süzerken dışarı çıktı.

Yanımızdaki, az önce konuşan iki adam da şaşkınlıkla bir bana bir kartala bakıyordu.

“Yalnız bu sefer kalbin de kırılacak, Prometheus,” dedi kartal, bana. “Belki son olur. Biliyorsun, bir sürü soruna neden oluyor bu yaptıkların.”

Beni koruyordu sözde. En çok kanıma dokunan buydu. Kasıklarımın üstüne oturmuş, kanlı suratının ardında gözleri parlarken attığı çığlık kulaklarımda titremeye devam ediyordu. Bu tabloda kimsenin kimseyi düşündüğü yoktu. Kartalın, yanımızdaki adamların, artık arkama kadar gelmiş olması gereken askerin, tren raylarının, geçmeyen saatlerin…

Arkamı döndüğümde, asker sahiden oradaydı. Zaten öyle olması gerekiyordu; görmüştüm bunu, biliyordum. Kehanetler… Bir şeyler söylüyordu ama ağzı oynarken sesi çıkmıyordu. Yavaşlamış, kendisini saatin akışına uydurmuştu. Havada donan tükürüğünden anlaşılıyordu, sinirliydi. Korktuğu için olduğunu biliyordum. Her seferinde korkmuşlardı. Beni unutmuş olmaları işlerini kolaylaştırmıyordu. Sadece yeni bir isim vermelerine neden oluyordu. Bu seferkiyle beni lanetleyecekleri kesinleşmişti.

Olması gerekenle olanların farklı olması ne kadar acınasıydı. Olması gerekenlerin doğasının kötücül olmasıysa bir yerde buna dayanıyordu.

“Salaksın,” dedi kartal bana. Zamanı aşan bir çığlık. Hepimizin önüne geçmişti ama kimseyi durduramıyordu.

Sonsuzluğa kaç tane iki saat sıkıştırabilirsiniz?

Ben bir tane bile sıkıştıramadım.

Çantama uzanıyordum. Asker de sırtındaki tüfeğini indiriyordu. Benim acelem yoktu, onunsa eli ayağı birbirine dolaşıyordu. Oysaki her şey tam olması gerektiği anda olacaktı. Kehanet başkasının parmaklarının ucundaydı.

Güneş, bir tüfeğin patlamasıyla yeryüzüne doğdu.

Rayların üzerine serilmiş göğsümün ortasından, bir çantanın içinden.

Not: Bu öykü ilk olarak 2021 yılında Esrarengiz Hikâyeler'de yayımlanmıştır.

@ 3bf0c63f:aefa459d

O Planetinha

Fumaça verde me entrando pelas narinas e um coro desafinado fazia uma base melódica.

nos confins da galáxia havia um planetinha isolado. Era um planeta feliz.

O homem vestido de mago começava a aparecer por detrás da fumaça verde.

O planetinha recebeu três presentes, mas o seu habitante, o homem, estava num estado de confusão tão grande que ameaçava estragá-los. Os homens já havia escravizado o primeiro presente, a vida; lutavam contra o segundo presente, a morte; e havia alguns que achavam que deviam destruir totalmente o terceiro, o amor, e com isto levar a desordem total ao pobre planetinha perdido, que se chamava Terra.

O coro desafinado entrou antes do "Terra" cantando várias vezes, como se imitasse um eco, "terra-terra-terraaa". Depois de uma pausa dramática, o homem vestido de mago voltou a falar.

Terra, nossa nave mãe.

Neste momento eu me afastei. À frente do palco onde o mago e seu coral faziam apelos à multidão havia vários estandes cobertos com a tradicional armação de quatro pernas e lona branca. Em todos os cantos da praça havia gente, gente dos mais variados tipos. Visitantes curiosos que se aproximavam atraídos pela fumaça verde e as barraquinhas, gente que aproveitava o movimento para vender doces sem pagar imposto, casais que se abraçavam de pé para espantar o frio, os tradicionais corredores que faziam seu cooper, gente cheia de barba e vestida para imitar os hippies dos anos 60 e vender colares estendidos no chão, transeuntes novos e velhos, vestidos como baladeiros ou como ativistas do ônibus grátis, grupos de ciclistas entusiastas.

O mago fazia agora apelos para que nós, os homens, habitantes do isolado planetinha, passássemos a ver o planetinha, nossa nave mãe, como um todo, e adquiríssemos a consciência de que ele estava entrando em maus lençóis. A idéia, reforçada pela logomarca do evento, era que parássemos de olhar só para a nossa vida e pensássemos no planeta.

A logomarca do evento, um desenho estilizado do planeta Terra, nada tinha a ver com seu nome: "Festival Andando de Bem com a Vida", mas havia sido ali colocada estrategicamente pelos organizadores, de quem parecia justamente sair a mensagem dita pelo mago.

Aquela multidão de pessoas que, assim como eu, tinham suas próprias preocupações, não podiam ver o quadro caótico que formavam, cada uma com seus atos isolados, ali naquela praça isolada, naquele planeta isolado. Quando o hippie barbudo, quase um Osho, assustava um casal para tentar vender-lhes um colar, a quantidade de caos que isto acrescentava à cena era gigantesca. Por um segundo, pude ver, como se estivesse de longe e acima, com toda a pretensão que este estado imaginativo carrega, a cena completa do caos.

---

Uma nave-mãe, dessas de ficção científica, habitada por milhões de pessoas, seguia no espaço sem rumo, e sem saber que logo à frente um longo precipício espacial a esperava, para a desgraça completa sua e de seus habitantes.

Acostumados àquela nave tanto quanto outrora estiveram acostumados à sua terra natal, os homens viviam as próprias vidas sem nem se lembrar que estavam vagando pelo espaço. Ninguém sabia quem estava conduzindo a nave, e ninguém se importava.

No final do filme descobre-se que era a soma completa do caos que cada habitante produzia, com seus gestos egoístas e incapazes de levar em conta a totalidade, é que determinava a direção da nave-mãe. O efeito, no entanto, não era imediato, como nunca é. Havia gente de verdade encarregada de conduzir a nave, mas era uma gente bêbada, mau-caráter, que vivia brigando pelo controle da nave e o poder que isto lhes dava. Poder, status, dinheiro!

Essa gente bêbada era atraída até ali pela corrupção das instituições e da moral comum que, no fundo no fundo, era causada pelo egoísmo da população, através de um complexo -- mas que no filme aparece simplificado pela ação individual de um magnata do divertimento público -- processo social.

O homem vestido de mago era mais um agente causador de caos, com sua cena cheia de fumaça e sua roupa estroboscópica, ele achava que estava fazendo o bem ao alertar sua platéia, todos as sextas-feiras, de que havia algo que precisava ser feito, que cada um que estava ali ouvindo era responsável pelo planeta. A sua incapacidade, porém, de explicar o que precisava ser feito só aumentava a angústia geral; a culpa que ele jogava sobre seu público, e que era prontamente aceita e passada em frente, aos familiares e amigos de cada um, atormentava-os diariamente e os impedia de ter uma vida decente no trabalho e em casa. As famílias, estressadas, estavam constantemente brigando e os motivos mais insignificantes eram responsáveis pelas mais horrendas conseqüências.

O mago, que após o show tirava o chapéu entortado e ia tomar cerveja num boteco, era responsável por uma parcela considerável do caos que levava a nave na direção do seu desgraçado fim. No filme, porém, um dos transeuntes que de passagem ouviu um pedaço do discurso do mago despertou em si mesmo uma consiência transformadora e, com poderes sobre-humanos que lhe foram então concedidos por uma ordem iniciática do bem ou não, usando só os seus poderes humanos mesmo, o transeunte -- na primeira versão do filme um homem, na segunda uma mulher -- consegue consertar as instituições e retirar os bêbados da condução da máquina. A questão da moral pública é ignorada para abreviar a trama, já com duas horas e quarenta de duração, mas subentende-se que ela também fora resolvida.

---

No planeta Terra real, que não está indo em direção alguma, preso pela gravidade ao Sol, e onde as pessoas vivem a própria vida porque lhes é impossível viver a dos outros, não têm uma consciência global de nada porque só é possível mesmo ter a consciência delas mesmas, e onde a maioria, de uma maneira ou de outra, está tentando como pode, fazer as coisas direito, o filme é exibido.

Para a maioria dos espectadores, é um filme que evoca reflexões, um filme forte. Por um segundo elas têm o mesmo vislumbre do caos generalizado que eu tive ali naquela praça. Para uma pequena parcela dos espectadores -- entre eles alguns dos que estavam na platéia do mago, o próprio mago, o seguidor do Osho, o casal de duas mulheres e o vendedor de brigadeiros, mas aos quais se somam também críticos de televisão e jornal e gente que fala pelos cotovelos na internet -- o filme é um horror, o filme é uma vulgarização de um problema real e sério, o filme apela para a figura do herói salvador e passa uma mensagem totalmente errada, de que a maioria da população pode continuar vivendo as suas própria vidinhas miseráveis enquanto espera por um herói que vem do Olimpo e os salva da mixórdia que eles mesmos causaram, é um filme que presta um enorme desserviço à causa.

No dia seguinte ao lançamento, num bar meio caro ali perto da praça, numa mesa com oito pessoas, entre elas seis do primeiro grupo e oito do segundo, discute-se se o filme levará ou não o Oscar. Eu estou em casa dormindo e não escuto nada.

@ f977c464:32fcbe00

Kendisini aynada ilk defa gördüğü o gün, diğerleri gibi olduğunu anlamıştı. Oysaki her insan biricik olmalıydı. Sözgelimi sinirlendiğinde bir kaşı diğerinden birkaç milimetre daha az çatılabilirdi veya sevindiğinde dudağı ona has bir açıyla dalgalanabilirdi. Hatta bunların hiçbiri mümkün değilse, en azından, gözlerinin içinde sadece onun sahip olabileceği bir ışık parlayabilirdi. Çok sıradan, öyle sıradan ki kimsenin fark etmediği o milyonlarca minik şeyden herhangi biri. Ne olursa.

Ama yansımasına bakarken bunların hiçbirini bulamadı ve diğer günlerden hiç de farklı başlamamış o gün, işe gitmek için vagonunun gelmesini beklediği alelade bir metro istasyonunda, içinde kaybolduğu illüzyon dağılmaya başladı.

İlk önce derisi döküldü. Tam olarak dökülmedi aslında, daha çok kıvılcımlara dönüşüp bedeninden fırlamış ve bir an sonra sönerek külleşmiş, havada dağılmıştı. Ardında da, kaybolmadan hemen önce, kısa süre için hayal meyal görülebilen, bir ruhun yok oluşuna ağıt yakan rengârenk peri cesetleri bırakmıştı. Beklenenin aksine, havaya toz kokusu yayıldı.

Dehşete düştü elbette. Dehşete düştüler. Panikle üstlerini yırtan 50 işçi. Her şeyin sebebiyse o vagon.

Saçları da döküldü. Her tel, yere varmadan önce, her santimde ikiye ayrıla ayrıla yok oldu.

Bütün yüzeylerin mat olduğu, hiçbir şeyin yansımadığı, suyun siyah aktığı ve kendine ancak kameralarla bakabildiğin bir dünyada, vagonun içine yerleştirilmiş bir aynadan ilk defa kendini görmek.

Gözlerinin akları buharlaşıp havada dağıldı, mercekleri boşalan yeri doldurmak için eriyip yayıldı. Gerçeği görmemek için yaratılmış, bu yüzden görmeye hazır olmayan ve hiç olmayacak gözler.

Her şeyin o anda sona erdiğini sanabilirdi insan. Derin bir karanlık ve ölüm. Görmenin görmek olduğu o anın bitişi.

---

Ben geldiğimde ölmüşlerdi.

Yani bozulmuşlardı demek istiyorum.

Belleklerini yeni taşıyıcılara takmam mümkün olmadı. Fiziksel olarak kusursuz durumdaydılar, olmayanları da tamir edebilirdim ama tüm o hengamede kendilerini baştan programlamış ve girdilerini modifiye etmişlerdi.

Belleklerden birini masanın üzerinden ileriye savurdu. Hınca hınç dolu bir barda oturuyorlardı. O ve arkadaşı.

Sırf şu kendisini insan sanan androidler travma geçirip delirmesin diye neler yapıyoruz, insanın aklı almıyor.

Eliyle arkasını işaret etti.

Polislerin söylediğine göre biri vagonun içerisine ayna yerleştirmiş. Bu zavallılar da kapı açılıp bir anda yansımalarını görünce kafayı kırmışlar.

Arkadaşı bunların ona ne hissettirdiğini sordu. Yani o kadar bozuk, insan olduğunu sanan androidi kendilerini parçalamış olarak yerde görmek onu sarsmamış mıydı?

Hayır, sonuçta belirli bir amaç için yaratılmış şeyler onlar. Kaliteli bir bilgisayarım bozulduğunda üzülürüm çünkü parasını ben vermişimdir. Bunlarsa devletin. Bana ne ki?

Arkadaşı anlayışla kafasını sallayıp suyundan bir yudum aldı. Kravatını biraz gevşetti.

Bira istemediğinden emin misin?

İstemediğini söyledi. Sahi, neden deliriyordu bu androidler?

Basit. Onların yapay zekâlarını kodlarken bir şeyler yazıyorlar. Yazılımcılar. Biliyorsun, ben donanımdayım. Bunlar da kendilerini insan sanıyorlar. Tiplerine bak.

Sesini alçalttı.

Arabalarda kaza testi yapılan mankenlere benziyor hepsi. Ağızları burunları bile yok ama şu geldiğimizden beri sakalını düzeltip duruyor mesela. Hayır, hepsi de diğerleri onun sakalı varmış sanıyor, o manyak bir şey.

Arkadaşı bunun delirmeleriyle bağlantısını çözemediğini söyledi. O da normal sesiyle konuşmaya devam etti.

Anlasana, aynayı falan ayırt edemiyor mercekleri. Lönk diye kendilerini görüyorlar. Böyle, olduğu gibi...

Nedenmiş peki? Ne gerek varmış?

Ne bileyim be abicim! Ahiret soruları gibi.

Birasına bakarak dalıp gitti. Sonra masaya abanarak arkadaşına iyice yaklaştı. Bulanık, bir tünelin ucundaki biri gibi, şekli şemalı belirsiz bir adam.

Ben seni nereden tanıyorum ki ulan? Kimsin sen?

Belleği makineden çıkardılar. İki kişiydiler. Soruşturmadan sorumlu memurlar.

─ Baştan mı başlıyoruz, diye sordu belleği elinde tutan ilk memur.

─ Bir kere daha deneyelim ama bu sefer direkt aynayı sorarak başla, diye cevapladı ikinci memur.

─ Bence de. Yeterince düzgün çalışıyor.

Simülasyon yüklenirken, ayakta, biraz arkada duran ve alnını kaşıyan ikinci memur sormaktan kendisini alamadı:

─ Bu androidleri niye böyle bir olay yerine göndermişler ki? Belli tost olacakları. İsraf. Gidip biz baksak aynayı kırıp delilleri mahvetmek zorunda da kalmazlar.

Diğer memur sandalyesinde hafifçe dönecek oldu, o sırada soruyu bilgisayarın hoparlöründen teknisyen cevapladı.

Hangi işimizde bir yamukluk yok ki be abi.

---

Ama bir son değildi. Üstlerindeki tüm illüzyon dağıldığında ve çıplak, cinsiyetsiz, birbirinin aynı bedenleriyle kaldıklarında sıra dünyaya gelmişti.

Yere düştüler. Elleri -bütün bedeni gibi siyah turmalinden, boğumları çelikten- yere değdiği anda, metronun zemini dağıldı.

Yerdeki karolar öncesinde beyazdı ve çok parlaktı. Tepelerindeki floresan, ışığını olduğu gibi yansıtıyor, tek bir lekenin olmadığı ve tek bir tozun uçmadığı istasyonu aydınlatıyorlardı.

Duvarlara duyurular asılmıştı. Örneğin, yarın akşam kültür merkezinde 20.00’da başlayacak bir tekno blues festivalinin cıvıl cıvıl afişi vardı. Onun yanında daha geniş, sarı puntolu harflerle yazılmış, yatay siyah kesiklerle çerçevesi çizilmiş, bir platformdan düşen çöp adamın bulunduğu “Dikkat! Sarı bandı geçmeyin!” uyarısı. Biraz ilerisinde günlük resmi gazete, onun ilerisinde bir aksiyon filminin ve başka bir romantik komedi filminin afişleri, yapılacakların ve yapılmayacakların söylendiği küçük puntolu çeşitli duyurular... Duvar uzayıp giden bir panoydu. On, on beş metrede bir tekrarlanıyordu.

Tüm istasyonun eni yüz metre kadar. Genişliği on metre civarı.

Önlerinde, açık kapısından o mendebur aynanın gözüktüğü vagon duruyordu. Metro, istasyona sığmayacak kadar uzundu. Bir kılıcın keskinliğiyle uzanıyor ama yer yer vagonların ek yerleriyle bölünüyordu.

Hiçbir vagonda pencere olmadığı için metronun içi, içlerindekiler meçhuldü.

Sonrasında karolar zerrelerine ayrılarak yükseldi. Floresanın ışığında her yeri toza boğdular ve ortalığı gri bir sisin altına gömdüler. Çok kısa bir an. Afişleri dalgalandırmadılar. Dalgalandırmaya vakitleri olmadı. Yerlerinden söküp aldılar en fazla. Işık birkaç kere sönüp yanarak direndi. Son kez söndüğünde bir daha geri gelmedi.

Yine de etraf aydınlıktı. Kırmızı, her yere eşit dağılan soluk bir ışıkla.

Yer tamamen tele dönüşmüştü. Altında çapraz hatlarla desteklenmiş demir bir iskelet. Işık birkaç metreden daha fazla aşağıya uzanamıyordu. Sonsuzluğa giden bir uçurum.

Duvarın yerini aynı teller ve demir iskelet almıştı. Arkasında, birbirine vidalarla tutturulmuş demir plakalardan oluşan, üstünden geçen boruların ek yerlerinden bazen ince buharların çıktığı ve bir süre asılı kaldıktan sonra ağır, yağlı bir havayla sürüklendiği bir koridor.

Diğer tarafta paslanmış, pencerelerindeki camlar kırıldığı için demir plakalarla kapatılmış külüstür bir metro. Kapının karşısındaki aynadan her şey olduğu gibi yansıyordu.

---

Bir konteynırın içini andıran bir evde, gerçi gayet de birbirine eklenmiş konteynırlardan oluşan bir şehirde “andıran” demek doğru olmayacağı için düpedüz bir konteynırın içinde, masaya mum görüntüsü vermek için koyulmuş, yarı katı yağ atıklarından şekillendirilmiş kütleleri yakmayı deniyordu. Kafasında hayvan kıllarından yapılmış grili siyahlı bir peruk. Aynı kıllardan kendisine gür bir bıyık da yapmıştı.

Üstünde mavi çöp poşetlerinden yapılmış, kravatlı, şık bir takım.

Masanın ayakları yerine oradan buradan çıkmış parçalar konulmuştu: bir arabanın şaft mili, üst üste konulmuş ve üstünde yazı okunamayan tenekeler, boş kitaplar, boş gazete balyaları... Hiçbir şeye yazı yazılmıyordu, gerek yoktu da zaten çünkü merkez veri bankası onları fark ettirmeden, merceklerden giren veriyi sentezleyerek insanlar için dolduruyordu. Yani, androidler için. Farklı şekilde isimlendirmek bir fark yaratacaksa.

Onların mercekleri için değil. Bağlantıları çok önceden kopmuştu.

─ Hayatım, sofra hazır, diye bağırdı yatak odasındaki karısına.

Sofrada tabak yerine düz, bardak yerine bükülmüş, çatal ve bıçak yerine sivriltilmiş plakalar.

Karısı salonun kapısında durakladı ve ancak kulaklarına kadar uzanan, kocasınınkine benzeyen, cansız, ölü hayvanların kıllarından ibaret peruğunu eliyle düzeltti. Dudağını, daha doğrusu dudağının olması gereken yeri koyu kırmızı bir yağ tabakasıyla renklendirmeyi denemişti. Biraz da yanaklarına sürmüştü.

─ Nasıl olmuş, diye sordu.

Sesi tek düzeydi ama hafif bir neşe olduğunu hissettiğinize yemin edebilirdiniz.

Üzerinde, çöp poşetlerinin içini yazısız gazete kağıtlarıyla doldurarak yaptığı iki parça giysi.

─ Çok güzelsin, diyerek kravatını düzeltti kocası.

─ Sen de öylesin, sevgilim.

Yaklaşıp kocasını öptü. Kocası da onu. Sonra nazikçe elinden tutarak, sandalyesini geriye çekerek oturmasına yardım etti.

Sofrada yemek niyetine hiçbir şey yoktu. Gerek de yoktu zaten.

Konteynırın kapısı gürültüyle tekmelenip içeri iki memur girene kadar birbirlerine öyküler anlattılar. O gün neler yaptıklarını. İşten erken çıkıp yemyeşil çimenlerde gezdiklerini, uçurtma uçurduklarını, kadının nasıl o elbiseyi bulmak için saatlerce gezip yorulduğunu, kocasının kısa süreliğine işe dönüp nasıl başarılı bir hamleyle yaşanan krizi çözdüğünü ve kadının yanına döndükten sonra, alışveriş merkezinde oturdukları yeni dondurmacının dondurmalarının ne kadar lezzetli olduğunu, boğazlarının ağrımasından korktuklarını...

Akşam film izleyebilirlerdi, televizyonda -boş ve mat bir plaka- güzel bir film oynayacaktı.

İki memur. Çıplak bedenleriyle birbirinin aynı. Ellerindeki silahları onlara doğrultmuşlardı. Mum ışığında, tertemiz bir örtünün serili olduğu masada, bardaklarında şaraplarla oturan ve henüz sofranın ortasındaki hindiye dokunmamış çifti gördüklerinde bocaladılar.

Hiç de androidlere bilinçli olarak zarar verebilecek gibi gözükmüyorlardı.

─ Sessiz kalma hakkına sahipsiniz, diye bağırdı içeri giren ikinci memur. Söylediğiniz her şey...

Cümlesini bitiremedi. Yatak odasındaki, masanın üzerinden gördüğü o şey, onunla aynı hareketleri yapan android, yoksa, bir aynadaki yansıması mıydı?

Bütün illüzyon o anda dağılmaya başladı.

Not: Bu öykü ilk olarak 2020 yılında Esrarengiz Hikâyeler'de yayımlanmıştır.

@ 8fb140b4:f948000c

Embarking on the journey of operating your own Lightning node on the Bitcoin Layer 2 network is more than just a tech-savvy endeavor; it's a step into a realm of financial autonomy and cutting-edge innovation. By running a node, you become a vital part of a revolutionary movement that's reshaping how we think about money and digital transactions. This role not only offers a unique perspective on blockchain technology but also places you at the heart of a community dedicated to decentralization and network resilience. Beyond the technicalities, it's about embracing a new era of digital finance, where you contribute directly to the network's security, efficiency, and growth, all while gaining personal satisfaction and potentially lucrative rewards.

In essence, running your own Lightning node is a powerful way to engage with the forefront of blockchain technology, assert financial independence, and contribute to a more decentralized and efficient Bitcoin network. It's an adventure that offers both personal and communal benefits, from gaining in-depth tech knowledge to earning a place in the evolving landscape of cryptocurrency.

Running your own Lightning node for the Bitcoin Layer 2 network can be an empowering and beneficial endeavor. Here are 10 reasons why you might consider taking on this task:

1. Direct Contribution to Decentralization: Operating a node is a direct action towards decentralizing the Bitcoin network, crucial for its security and resistance to control or censorship by any single entity.

2. Financial Autonomy: Owning a node gives you complete control over your financial transactions on the network, free from reliance on third-party services, which can be subject to fees, restrictions, or outages.

3. Advanced Network Participation: As a node operator, you're not just a passive participant but an active player in shaping the network, influencing its efficiency and scalability through direct involvement.

4. Potential for Higher Revenue: With strategic management and optimal channel funding, your node can become a preferred route for transactions, potentially increasing the routing fees you can earn.

5. Cutting-Edge Technological Engagement: Running a node puts you at the forefront of blockchain and bitcoin technology, offering insights into future developments and innovations.

6. Strengthened Network Security: Each new node adds to the robustness of the Bitcoin network, making it more resilient against attacks and failures, thus contributing to the overall security of the ecosystem.

7. Personalized Fee Structures: You have the flexibility to set your own fee policies, which can balance earning potential with the service you provide to the network.

8. Empowerment Through Knowledge: The process of setting up and managing a node provides deep learning opportunities, empowering you with knowledge that can be applied in various areas of blockchain and fintech.

9. Boosting Transaction Capacity: By running a node, you help to increase the overall capacity of the Lightning Network, enabling more transactions to be processed quickly and at lower costs.

10. Community Leadership and Reputation: As an active node operator, you gain recognition within the Bitcoin community, which can lead to collaborative opportunities and a position of thought leadership in the space.

These reasons demonstrate the impactful and transformative nature of running a Lightning node, appealing to those who are deeply invested in the principles of bitcoin and wish to actively shape its future. Jump aboard, and embrace the journey toward full independence. 🐶🐾🫡🚀🚀🚀

@ 8fb140b4:f948000c

Chef's notes

Serving these two dishes together will create a delightful centerpiece for your Thanksgiving meal, offering a perfect blend of traditional flavors with a homemade touch.

Details

• ⏲️ Prep time: 30 min
• 🍳 Cook time: 1 - 2 hours
• 🍽️ Servings: 4-6

Ingredients

• 1 whole turkey (about 12-14 lbs), thawed and ready to cook
• 1 cup unsalted butter, softened
• 2 tablespoons fresh thyme, chopped
• 2 tablespoons fresh rosemary, chopped
• 2 tablespoons fresh sage, chopped
• Salt and freshly ground black pepper
• 1 onion, quartered
• 1 lemon, halved
• 2-3 cloves of garlic
• Apple and Sage Stuffing
• 1 loaf of crusty bread, cut into cubes
• 2 apples, cored and chopped
• 1 onion, diced
• 2 stalks celery, diced
• 3 cloves garlic, minced
• 1/4 cup fresh sage, chopped
• 1/2 cup unsalted butter
• 2 cups chicken broth
• Salt and pepper, to taste

Directions

1. Preheat the Oven: Set your oven to 325°F (165°C).
2. Prepare the Herb Butter: Mix the softened butter with the chopped thyme, rosemary, and sage. Season with salt and pepper.
3. Prepare the Turkey: Remove any giblets from the turkey and pat it dry. Loosen the skin and spread a generous amount of herb butter under and over the skin.
4. Add Aromatics: Inside the turkey cavity, place the quartered onion, lemon halves, and garlic cloves.
5. Roast: Place the turkey in a roasting pan. Tent with aluminum foil and roast. A general guideline is about 15 minutes per pound, or until the internal temperature reaches 165°F (74°C) at the thickest part of the thigh.
6. Rest and Serve: Let the turkey rest for at least 20 minutes before carving.
7. Next: Apple and Sage Stuffing
8. Dry the Bread: Spread the bread cubes on a baking sheet and let them dry overnight, or toast them in the oven.
9. Cook the Vegetables: In a large skillet, melt the butter and cook the onion, celery, and garlic until soft.
10. Combine Ingredients: Add the apples, sage, and bread cubes to the skillet. Stir in the chicken broth until the mixture is moist. Season with salt and pepper.
11. Bake: Transfer the stuffing to a baking dish and bake at 350°F (175°C) for about 30-40 minutes, until golden brown on top.

@ 8fb140b4:f948000c

Testing a brand new YakiHonne native client for iOS. Smooth as butter (not penis butter 🤣🍆🧈) with great visual experience and intuitive navigation. Amazing work by the team behind it! * lists * work

Bold text work!

Images could have used nostr.build instead of raw S3 from us-east-1 region.

Very impressive! You can even save the draft and continue later, before posting the long-form note!

🐶🐾🤯🤯🤯🫂💜

@ fa0165a0:03397073

I just tested building a browser plugin, it was easier than I thought. Here I'll walk you through the steps of creating a minimal working example of a browser plugin, a.k.a. the "Hello World" of browser plugins.

First of all there are two main browser platforms out there, Chromium and Mozilla. They do some things a little differently, but similar enough that we can build a plugin that works on both. This plugin will work in both, I'll describe the firefox version, but the chromium version is very similar.

What is a browser plugin?

Simply put, a browser plugin is a program that runs in the browser. It can do things like modify the content of a webpage, or add new functionality to the browser. It's a way to extend the browser with custom functionality. Common examples are ad blockers, password managers, and video downloaders.

In technical terms, they are plugins that can insert html-css-js into your browser experience.

How to build a browser plugin

Step 0: Basics

You'll need a computer, a text editor and a browser. For testing and development I personally think that the firefox developer edition is the easiest to work with. But any Chrome based browser will also do.

Create a working directory on your computer, name it anything you like. I'll call mine hello-world-browser-plugin. Open the directory and create a file called manifest.json. This is the most important file of your plugin, and it must be named exactly right.

Step 1: manifest.json

After creation open your file manifest.json in your text editor and paste the following code:

json { "manifest_version": 3, "name": "Hello World", "version": "1.0", "description": "A simple 'Hello World' browser extension", "content_scripts": [ { "matches": ["<all_urls>"], "js": ["hello.js"] //The name of your script file. // "css": ["hello.css"] //The name of your css file. } ] }

If you wonder what the json file format is, it's a normal text file with a special syntax such that a computer can easily read it. It's the json syntax you see in the code above. Let's go through what's being said here. (If you are not interested, just skip to the next step after pasting this we are done here.)

• manifest_version: This is the version of the manifest file format. It's currently at version 3, and it's the latest version. It's important that you set this to 3, otherwise your plugin won't work.
• name: This is the name of your plugin. It can be anything you like.
• version: This is the version of your plugin. It can be anything you like.
• description: This is the description of your plugin. It can be anything you like.
• content_scripts: This is where you define what your plugin does. It's a list of scripts that will be executed when the browser loads a webpage. In this case we have one script, called hello.js. It's the script that we'll create in the next step.
• matches: This is a list of urls that the script will be executed on. In this case we have <all_urls>, which means that the script will be executed on all urls. You can also specify a specific url, like https://brave.com/*, which means that the script will only be executed on urls that start with https://brave.com/.
• js: This is a list of javascript files that will be executed. In this case we have one file, called hello.js. It's the script that we'll create in the next step.
• css: This is where you can add a list of css files that will be executed. In this case we have none, but you can add css files here if you want to.
• //: Text following these two characters are comments. They are ignored by the computer, You can add comments anywhere you like, and they are a good way to document your code.

Step 2: hello.js

Now it's time to create another file in your project folder. This time we'll call it hello.js. When created, open it in your text editor and paste the following code:

js console.log("Hello World!"); That's javascript code, and it's what will be executed when you run your plugin. It's a simple console.log statement, which will print the text "Hello World!" to the console. The console is a place where the browser prints out messages, and it's a good place to start when debugging your plugin.

Step 3: Load and launch your plugin

Firefox

Now it's time to load your plugin into your browser. Open your browser and go to the url about:debugging#/runtime/this-firefox. You should see a page that looks something like this:

Click the button that says "Load Temporary Add-on...". A file dialog will open, navigate to your project folder and select the file manifest.json. Your plugin should now be loaded and running.

Go to a website, any website, and open the inspector then navigate to the console. You'll find the inspector by right-clicking anywhere within the webpage, and click "Inspector" in the drop-down menu. When opening the console you might see some log messages from the site you visited and... you should see the text "Hello World!" printed there, from our little plugin! Congratulations!

Chrome

Open your browser and go to the url chrome://extensions/. Click the button that says "Load unpacked". A file dialog will open, navigate to your project folder and select the folder hello-world-browser-plugin. Your plugin should now be loaded and running.

Note the difference, of selecting the file manifest.json in firefox, and selecting the folder hello-world-browser-plugin in chrome. Otherwise, the process is the same. So I'll repeat the same text as above: (for those who skipped ahead..)

Go to a website, any website, and open the inspector then navigate to the console. You'll find the inspector by right-clicking anywhere within the webpage, and click "Inspector" in the drop-down menu. When opening the console you might see some log messages from the site you visited and... you should see the text "Hello World!" printed there, from our little plugin! Congratulations!

---

As you can see this isn't as complicated as one might think. Having preformed a "Hello-World!"-project is a very useful and valuable first step. These setup steps are the basics for any browser plugin, and you can build on this to create more advanced plugins.

@ 8fb140b4:f948000c

As the title states, scratch behind my ear and you get it. 🐶🐾🫡

@ 8fb140b4:f948000c

Test Bounty Note

@ 8fb140b4:f948000c

Intro

This short tutorial will help you set up your own Nostr Wallet Connect (NWC) on your own LND Node that is not using Umbrel. If you are a user of Umbrel, you should use their version of NWC.

Requirements

You need to have a working installation of LND with established channels and connectivity to the internet. NWC in itself is fairly light and will not consume a lot of resources. You will also want to ensure that you have a working installation of Docker, since we will use a docker image to run NWC.

• Working installation of LND (and all of its required components)
• Docker (with Docker compose)

Installation

For the purpose of this tutorial, we will assume that you have your lnd/bitcoind running under user bitcoin with home directory /home/bitcoin. We will also assume that you already have a running installation of Docker (or docker.io).

Prepare and verify

git version - we will need git to get the latest version of NWC. docker version - should execute successfully and show the currently installed version of Docker. docker compose version - same as before, but the version will be different. ss -tupln | grep 10009- should produce the following output: tcp LISTEN 0 4096 0.0.0.0:10009 0.0.0.0: tcp LISTEN 0 4096 [::]:10009 [::]:**

For things to work correctly, your Docker should be version 20.10.0 or later. If you have an older version, consider installing a new one using instructions here: https://docs.docker.com/engine/install/

Create folders & download NWC

In the home directory of your LND/bitcoind user, create a new folder, e.g., "nwc" mkdir /home/bitcoin/nwc. Change to that directory cd /home/bitcoin/nwc and clone the NWC repository: git clone https://github.com/getAlby/nostr-wallet-connect.git

Creating the Docker image

In this step, we will create a Docker image that you will use to run NWC.

• Change directory to nostr-wallet-connect: cd nostr-wallet-connect
• Run command to build Docker image: docker build -t nwc:$(date +'%Y%m%d%H%M') -t nwc:latest . (there is a dot at the end)
• The last line of the output (after a few minutes) should look like => => naming to docker.io/library/nwc:latest
• nwc:latest is the name of the Docker image with a tag which you should note for use later.

Creating docker-compose.yml and necessary data directories

• Let's create a directory that will hold your non-volatile data (DB): mkdir data
• Indocker-compose.ymlfile, there are fields that you want to replace (<> comments) and port “4321” that you want to make sure is open (check with ss -tupln | grep 4321which should return nothing).
• Create docker-compose.ymlfile with the following content, and make sure to update fields that have <> comment:

version: "3.8" services: nwc: image: nwc:latest volumes: - ./data:/data - ~/.lnd:/lnd:ro ports: - "4321:8080" extra_hosts: - "localhost:host-gateway" environment: NOSTR_PRIVKEY: <use "openssl rand -hex 32" to generate a fresh key and place it inside ""> LN_BACKEND_TYPE: "LND" LND_ADDRESS: localhost:10009 LND_CERT_FILE: "/lnd/tls.cert" LND_MACAROON_FILE: "/lnd/data/chain/bitcoin/mainnet/admin.macaroon" DATABASE_URI: "/data/nostr-wallet-connect.db" COOKIE_SECRET: <use "openssl rand -hex 32" to generate fresh secret and place it inside ""> PORT: 8080 restart: always stop_grace_period: 1m

Starting and testing

Now that you have everything ready, it is time to start the container and test.

• While you are in the nwcdirectory (important), execute the following command and check the log output, docker compose up
• You should see container logs while it is starting, and it should not exit if everything went well.
• At this point, you should be able to go to http://<ip of the host where nwc is running>:4321 and get to the interface of NWC
• To stop the test run of NWC, simply press Ctrl-C , and it will shut the container down.
• To start NWC permanently, you should execute docker compose up -d , “-d” tells Docker to detach from the session.
• To check currently running NWC logs, execute docker compose logs to run it in tail mode add -f to the end.
• To stop the container, execute docker compose down

That's all, just follow the instructions in the web interface to get started.

Updating

As with any software, you should expect fixes and updates that you would need to perform periodically. You could automate this, but it falls outside of the scope of this tutorial. Since we already have all of the necessary configuration in place, the update execution is fairly simple.

• Change directory to the clone of the git repository, cd /home/bitcoin/nwc/nostr-wallet-connect
• Run command to build Docker image: docker build -t nwc:$(date +'%Y%m%d%H%M') -t nwc:latest . (there is a dot at the end)
• Change directory back one level cd ..
• Restart (stop and start) the docker compose config docker compose down && docker compose up -d
• Done! Optionally you may want to check the logs: docker compose logs

@ 82341f88:fbfbe6a2

There’s a lot of conversation around the #TwitterFiles. Here’s my take, and thoughts on how to fix the issues identified.

I’ll start with the principles I’ve come to believe…based on everything I’ve learned and experienced through my past actions as a Twitter co-founder and lead:

1. Social media must be resilient to corporate and government control.
2. Only the original author may remove content they produce.
3. Moderation is best implemented by algorithmic choice.

The Twitter when I led it and the Twitter of today do not meet any of these principles. This is my fault alone, as I completely gave up pushing for them when an activist entered our stock in 2020. I no longer had hope of achieving any of it as a public company with no defense mechanisms (lack of dual-class shares being a key one). I planned my exit at that moment knowing I was no longer right for the company.

The biggest mistake I made was continuing to invest in building tools for us to manage the public conversation, versus building tools for the people using Twitter to easily manage it for themselves. This burdened the company with too much power, and opened us to significant outside pressure (such as advertising budgets). I generally think companies have become far too powerful, and that became completely clear to me with our suspension of Trump’s account. As I’ve said before, we did the right thing for the public company business at the time, but the wrong thing for the internet and society. Much more about this here: https://twitter.com/jack/status/1349510769268850690

I continue to believe there was no ill intent or hidden agendas, and everyone acted according to the best information we had at the time. Of course mistakes were made. But if we had focused more on tools for the people using the service rather than tools for us, and moved much faster towards absolute transparency, we probably wouldn’t be in this situation of needing a fresh reset (which I am supportive of). Again, I own all of this and our actions, and all I can do is work to make it right.

Back to the principles. Of course governments want to shape and control the public conversation, and will use every method at their disposal to do so, including the media. And the power a corporation wields to do the same is only growing. It’s critical that the people have tools to resist this, and that those tools are ultimately owned by the people. Allowing a government or a few corporations to own the public conversation is a path towards centralized control.

I’m a strong believer that any content produced by someone for the internet should be permanent until the original author chooses to delete it. It should be always available and addressable. Content takedowns and suspensions should not be possible. Doing so complicates important context, learning, and enforcement of illegal activity. There are significant issues with this stance of course, but starting with this principle will allow for far better solutions than we have today. The internet is trending towards a world were storage is “free” and infinite, which places all the actual value on how to discover and see content.

Which brings me to the last principle: moderation. I don’t believe a centralized system can do content moderation globally. It can only be done through ranking and relevance algorithms, the more localized the better. But instead of a company or government building and controlling these solely, people should be able to build and choose from algorithms that best match their criteria, or not have to use any at all. A “follow” action should always deliver every bit of content from the corresponding account, and the algorithms should be able to comb through everything else through a relevance lens that an individual determines. There’s a default “G-rated” algorithm, and then there’s everything else one can imagine.

The only way I know of to truly live up to these 3 principles is a free and open protocol for social media, that is not owned by a single company or group of companies, and is resilient to corporate and government influence. The problem today is that we have companies who own both the protocol and discovery of content. Which ultimately puts one person in charge of what’s available and seen, or not. This is by definition a single point of failure, no matter how great the person, and over time will fracture the public conversation, and may lead to more control by governments and corporations around the world.

I believe many companies can build a phenomenal business off an open protocol. For proof, look at both the web and email. The biggest problem with these models however is that the discovery mechanisms are far too proprietary and fixed instead of open or extendable. Companies can build many profitable services that complement rather than lock down how we access this massive collection of conversation. There is no need to own or host it themselves.

Many of you won’t trust this solution just because it’s me stating it. I get it, but that’s exactly the point. Trusting any one individual with this comes with compromises, not to mention being way too heavy a burden for the individual. It has to be something akin to what bitcoin has shown to be possible. If you want proof of this, get out of the US and European bubble of the bitcoin price fluctuations and learn how real people are using it for censorship resistance in Africa and Central/South America.

I do still wish for Twitter, and every company, to become uncomfortably transparent in all their actions, and I wish I forced more of that years ago. I do believe absolute transparency builds trust. As for the files, I wish they were released Wikileaks-style, with many more eyes and interpretations to consider. And along with that, commitments of transparency for present and future actions. I’m hopeful all of this will happen. There’s nothing to hide…only a lot to learn from. The current attacks on my former colleagues could be dangerous and doesn’t solve anything. If you want to blame, direct it at me and my actions, or lack thereof.

As far as the free and open social media protocol goes, there are many competing projects: @bluesky is one with the AT Protocol, nostr another, Mastodon yet another, Matrix yet another…and there will be many more. One will have a chance at becoming a standard like HTTP or SMTP. This isn’t about a “decentralized Twitter.” This is a focused and urgent push for a foundational core technology standard to make social media a native part of the internet. I believe this is critical both to Twitter’s future, and the public conversation’s ability to truly serve the people, which helps hold governments and corporations accountable. And hopefully makes it all a lot more fun and informative again.

💸🛠️🌐 To accelerate open internet and protocol work, I’m going to open a new category of #startsmall grants: “open internet development.” It will start with a focus of giving cash and equity grants to engineering teams working on social media and private communication protocols, bitcoin, and a web-only mobile OS. I’ll make some grants next week, starting with $1mm/yr to Signal. Please let me know other great candidates for this money.