Application Layer
This section covers the design and implementation of the Portrait application layer. The application layer is responsible for interacting with the Portrait protocol and providing users with a seamless and secure experience.
Overview
Introduction
This page focuses on how the Portrait application layer interacts with the Portrait protocol, and the design choices that have been made to ensure a seamless and secure user experience while maintaining the integrity and verifiability of the data associated with a Portrait. In addition, this page should help you understand the various components of the Portrait application layer and how they work together to provide users with a reliable and efficient experience.
This page is written to be completely transparent about the design and implementation of the application layer. If you believe that there are areas that need further clarification or if you have any questions, reach out to us on Discord (opens in a new tab).
License
The Portrait Protocol is open source, enabling transparency and inviting community contributions. While the application layer is under active development and remains closed source for now, we are considering open sourcing it in the future. Currently, it remains proprietary to protect our team's intellectual property and to safeguard against potential security exploits.
Optimistic Rendering
Portrait employs optimistic rendering to enhance user experience. When a user visits a Portrait, the application layer renders the Portrait optimistically, displaying the data before it is fully verified. This approach ensures that users can access the data quickly while the application layer verifies the data in the background.
Off-Protocol Implementations
Portrait includes off-protocol implementations that enhance the user experience. These implementations are not part of the Portrait protocol but are implemented by the application layer to provide additional functionality and features to users. As of now, status updates are one such off-protocol implementation.
Embedded Wallets
Jargon and complexity often deter new users. Portrait accounts are registered in on-chain smart contracts, linking them to Ethereum addresses. These addresses are typically managed by what is commonly called a "wallet." However, for those not versed in the web3 ecosystem, the term "wallet" can be misleading.
Consider this: When you hear "wallet," do you think of a digital account or an object that stores money and cards?
Imagine telling a friend, "I need to connect my wallet to open my Netflix app." They might think you're updating your payment method, not signing into your account.
The term "wallet" originated from traditional finance when Bitcoin first emerged. It doesn’t quite fit the web3 context. That’s why Portrait uses "account" instead of "wallet" to make the concept more intuitive.
Additionally, most blockchain wallets cater to tech-savvy individuals, often involving complex cryptographic keys and seed phrases, and are associated with financial transactions or investments.
Portrait has nothing to do with financial transactions or investments. This is why we abstract the account management process. You sign in with your email address and receive a one-time password. Behind the scenes, your account is still linked to an Ethereum address through Coinbase Embedded Wallets (opens in a new tab).
We do support direct connections with wallets like MetaMask or Rainbow, but they are secondary options.
Delegating Transactions
To improve user experience, users may delegate transactions to our service. This allows users to interact with the Portrait protocol without having to manage the transaction process themselves. Delegating transactions is an optional feature and is designed to simplify the user experience while maintaining the security and integrity of the Portrait protocol. During the beta, we are handling all transactions for all users.
User Uploads
To compress the data of a Portrait, user uploads are offloaded to IPFS/Filecoin and Arweave, which are decentralized storage protocols. The user uploads are stored on these networks, and the Portrait object references the data using Content Identifier (CID). This approach ensures that the data is available and accessible while minimizing the storage requirements for hosting nodes.
Local-First Hosting Communication
In a desktop environment, the Portrait application layer adopts a local-first approach to interact directly with the hosting node. By leveraging local communication channels over the localhost interface, we eliminate the need for centralized servers or cloud services.
This method substantially reduces latency and enhances privacy, as all data processing and transmission are confined to the user's environment. The result is faster data exchanges, improved security, and a more reliable system. By prioritizing local interactions, we create a resilient and user-centric platform that delivers a superior experience and upholds the highest standards of data integrity and privacy.
Hosting requirements
To start hosting within the application, users must install a progressive web app on their device. This ensures they have the necessary resources and stability to manage data associated with Portraits. Simply using a browser is not sufficient, as we store the state in IndexedDB, which browsers may periodically clear or allow extensions to access. Persistent, reliable, and accurate performance by hosting nodes is essential for the effective functioning of the Portrait protocol.