You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Competing versions of Concorde's UI and business logic ("app versions") must execute in an environment that provides the minimal infrastructure that enables developers to easily build and effectively fork multiplayer applications.
The client is responsible for securely running app versions and storing user data, such as private keys, contact lists, and group chat logs.
Tenets
Trust
On the modern web, everyone must treat each other like adversaries. The app developer assumes that all users are a potential threat. The users are wary of executing code provided by the app developer and do not trust the app developer with their data. Furthermore, users are often skeptical of each other. For example, a user may trust their friend on Twitter, but doesn't trust a user they don't know.
This makes running developing a web app like operating a business in a war zone. It creates overhead and inhibits activity. It also has a major implications for forking.
Company need to take certain measures to to secure user data. This includes storing data in private databases. This means data is not portable from one version of an app to its fork.
Companies must vet developers that wish to contribute to their engineering efforts. They must be skeptical that these developers could introduce malicious or even accidentally vulnerable code.
Users must be cautious when adopting forks. Just because they trust the original version of an app does not mean that they can trust a forked version.
By forcing all network connectivity to go through a E2EE messaging protocol, it means that users only must trust other members of their group. Assuming they trust the Concorde protocol, they can then switch between many different app versions without concern. Furthermore, developers can collaborate freely since the Concorde protocol is designed with great care to prevent data leak attack vectors.
The web browser is the best app
The web browser is the most useful app on your computer. It has so much functionality and the amount of things you can do on it grows exponentially over time. This is because it provides two things:
A trusted environment to execute code (you are much more likely to feel safe visiting a website rather than running an executable application on your OS)
Switching between websites is really easy
Web browser developers didn't build this amazing functionality. They simply created an environment for this type of functionality to evolve. They harnessed a market to build out its functionality.
The metaverse is a messaging app
Roughly speaking, the metaverse is a collection of virtual worlds that people can jump between. They can go to different locations with their friends and do different things socially.
Technically speaking, a given virtual world within the metaverse is custom frontend for a group chat. Let's say you are in a virtual space. If you update your position, you will need to notify all other people in that space of your change in position. In doing so, you are essentially sending a "message" to them telling them that you have moved.
Concorde is a group chat with an evolving frontend. The web browser is capable of rendering AAA graphics and can even power VR experiences. Using web browser technology on the frontend and a secure, private, decentralized messaging protocol on that backend, Concorde is essentially a metaverse play.
This is especially exciting when you consider the fact that these metaverse worlds are analogous to "app versions" inside of Concorde and can improve exponentially over time (for more information on how this would work, see #8).
Improved data portability across devices (multi-device)
Devices are not required to always be connected to the Internet (offline)
It can have collaborative features (collaboration)
If the company developing the software goes under, the user does not lose access (longevity)
Better security and privacy (privacy)
Users own their own data (user control)
When applying this rubric to a variety of apps, they come up with following rubric
Concorde is an opinionated operating system for local-first software.
This is because Concorde is intended to be a high-performance syncing layer for append-only logs with an execution environment for frontends using this data model. These logs can contain CRDTs that enable the full suite of local first software benefits
CRDTs have the potential to be a foundation for a new generation of software. Just as packet switching was an enabling technology for the Internet and the web, or as capacitive touchscreens were an enabling technology for smartphones, so we think CRDTs may be the foundation for collaborative software that gives users full ownership of their data.
What is beautiful about the messaging app use case is that much functionality can work according to these local-first ideals without even needing CRDTs (but can use them in order to build more complex user experiences). And by utilizing FRP, this makes the developer experience really nice.
Because the FRP model reliably synchronizes the visible state of the application with the underlying state of the shared document, the developer is freed from the tedious work of tracking changes arriving from other users and reconciling them with the current view. Also, by ensuring all changes to the underlying state are made through a single function (a “reducer”), it’s easy to ensure that all relevant local changes are sent to other users.
The result of this model was that all of our prototypes realized real-time collaboration and full offline capability with little effort from the application developer. This is a significant benefit as it allows app developers to focus on their application rather than the challenges of data distribution.
Plan and Questions
Concorde is a messaging app. Users congregate in groups and send messages to each other through a decentralized protocol (see #4). What makes Concorde unique is how it handles message data.
Concorde allows groups to install custom frontends that determine how messages within a group are sent and interpreted. These custom frontends are also known as app versions, because they are all different versions of the same group chat experience built by competing teams of developers. For the sake of brevity, these different app versions may be referred to simply as apps.
Let's say two users want to chat. One will first invite the other to a group.
Next, they will decide which app version they want to use within this group. We will call the one they choose "App 1".
When they use an app version, they download its full source code. This ensures that all apps in the ecosystem are open source and forkable.
After the code is downloaded, it is executed in a secure environment (WebView) that is prevented from accessing the Internet
When a user takes an action in the app, they let other users in the group know by sending them an encrypted message using the protocol (see #4).
So where does the client fit into this system? The client is the application running on the user's device that connects to the protocol and provides the environment for the different app versions to execute. You can think of it as a thin shell that wraps around the app version to provide the minimal infrastructure to make Concorde possible.
To illustrate, let's walk through one more example—this time with more detail about the client's role.
Using the client's UI, one user will invite another to a group. Once they are in a group, the two clients will initiate a connection to each other using the protocol and download the same app version. There will be a default app version that can be changed in the group admin's client UI. Again, we will call this app version "App 1".
Before any messages have been sent in the group, it will probably be a blank screen. In reality, it may look different. It depends on how the developers implemented the app version being used. For the sake of this example, imagine it looks like this.
Then let's say that User 1 types the message "gm" and clicks the "send" button in the UI. This will call a hook in the WebView that tells the client to send a message over the protocol letting User 2 know that User 1 said "gm". Technically speaking, this message might look like the following: { "action": "message", "payload": { "id": 1, "body": "gm" } }. With that said, developers of "App 1" are in full control of the message schema, how messages are constructed, and when messages are sent.
Once this message is sent over the protocol, the clients store it locally. They then update the state of the frontend by triggering an event inside the WebView, delivering the message to the app.
A similar process happens when User 2 "hearts" User 1's message: { "action": "react", "payload": { "targetId": 1, "emoji": ":heart:" } }
Now let's imagine that User 1 changes the app version to "App 2". This new custom frontend will take the old state and render it differently. It also may have different rules for how sends new messages to generate new state.
The client will do this by downloading the new source code, opening it in the WebView, and retrieving the old message log from local storage and it as them as the initial state for the app inside of the WebView.
In summary, the full list of high-level client responsibilities are as follows. The client...
Allows users to...
Generate and manage private keys
Add other users to group chats
Switch between group chats
Decide which version of Concorde to use in a given group chat (each group chat can use a different version)
Provides...
A sandboxed execution environment for Concorde to run
An API for Concorde to send, receive, and store messages with other members of a group
Phase 0: Single Purpose
Status:In Progress
The purpose of this phase is to enable developers to get started and build the app execution environment. During this phase, Concorde will only support a single, global group for all users. All users will be running the same app version. However, developers will be able to launch into their own groups and app versions for testing purposes (however, this will be a part of #7). The client will be built using Electron for desktop users only.
Components
Execution environment
The default app version ("the app") will be initially bundled with the Concorde binary. The the app will load in a WebView (the standard Electron renderer). It should be set to disallow network requests.
Protocol integration
Upon initially opening Concorde, public/private key will be generated for the user and these will be used to interact with the protocol (see #4).
When an action takes place, an emit-messageIPC event will be triggered in the renderer and will be read by the main process and passed to the protocol as a message.
When the protocol receives a message, the main process will send it into the renderer as a receive-message event.
In order to connect to the protocol, the main process will start a daemon that maintains a connection in the background and communicates with the main process to pass messages to and from the renderer. When a message is sent or received, the daemon will add the new message to a chat log file. When the client initially starts, it will take the contents of this file and inject it using contextBridge inside a preload script setting it to window._concordeInitialState.
Milestones
Execution environment
Protocol daemon
Message passing
Key management
Questions
What security concerns need to be taken into consideration while running untrusted code inside the Electron renderer? "Rendering untrusted content in Electron is still somewhat uncharted territory, though some apps are finding success (e.g. Beaker Browser). Our goal is to get as close to Chrome as we can in terms of the security of sandboxed content, but ultimately we will always be behind due to a few fundamental issues..."
Will message passing through the main process cause performance issues? "The Chromium process architecture means that any blocking code in the main process will block the renderers too."
What is the best way to implement the daemon and key management?
Phase 1: Full UI
Status:Planning
Once phase 0 is complete, the app will be usable and developers will be able to begin iterating on the frontend. However, the possibilities will be severely limited. Phase 1 is intended to bring the full suite of client features to Concorde. This includes the following components.
There is a large amount of ambiguity here because this is dependent on UI designs and product planning. If anyone wants to wifeframe and prototype the UX, it would be greatly appreciated. As a result of this ambiguity, this section will be laid out slightly differently.
Contacts
Status
Planned
Completed
Description
Users will be able to add other contacts based on their public key (QR code or string). They will also be able to set a preferred name for that contact. In conjunction, users will be able to set the preferred name for themselves that will serve as the default contact name in other's "contact book".
Contacts will be stored locally in a directory and will be able to be edited and removed. When starting a new group chat, users will be able to type out contacts' names and send invitations with autocompletion.
Questions
UI/UX Needed.
Should this integrate with any other services, such as IDX?
Is this really necessary? Perhaps all invitations can be sent out of band (i.e. click this magic link to join the group).
How will users be notified of invitations?
Creating, joining, and managing one or more groups
Status
Planned
Completed
Description
Users should be able to create groups and set the group name. If the user has created the group, they will be considered the "admin" and will therefore be able to select which version of the app is running in the group (see below). Admins will be able to set and remove other members as admins, but the founding admin cannot be removed by other admins. The founding admin must resign (and cannot do so if there are no other admins. This process will be facilitated by the protocol (see #4).
The following are called "exit events":
Users can leave a group. They do this by simply ignoring the group chat. Using the protocol, they can notify other group members that they are leaving and these other clients can automatically create a new group chat with all the members except the one who left.
Users can be booted from a group by an admin using the protocol to notify all other members to automatically switch to another group without the booted user.
In both of exit event cases, users that automatically switch over ignore the old group and the old data is brought over to the new group.
Invitations must be opt-in. You can use the protocol to construct a group with any set of members, if you know their public key. However, that only whitelists them into the group. The client will ignore the existence of such groups until the user opts-in by accepting an invitation or automatically joining due to an exit event.
Moderation tools (such as hiding messages) will be implemented by the app version developers and not the client.
There will also be a user interface with a list of group chat so the user can open into different groups. Selecting a group opens up the app version inside a renderer window. The list will have some sort of indication if there is new activity in the group.
Questions
UI/UX Needed.
What is the best way to display notifications of new activity? Ideally, there would be a secure way that the app developer can parse incoming messages to display description notification information. This is challenging because the number of notifications may be different than the number of messages. It would be easy to display a "5" when there are five messages in the group since the user last opened it. But perhaps not all of those messages are notification worthy or perhaps they were never read and should not be reset upon simply opening the chat window. Further, since the client does not make assumptions about the schema of messages, there is no universal way to summarize the content of a notification or message. This would need to be specified by the app developer. Lastly, it would be ideal for all of this to (1) be easy for developers to work with and (2) not require the renderer window to be open in order to display notification information.
Changing app versions within groups
Status
Planned
Completed
Description
Under the hood, Concorde allows groups to run multiple app versions at once. However, at this phase there is only 1 active app version at a time. Apps running inside of groups have three properties:
App version
Instance ID
App data
The client will provide a directory of suggested app versions as well as an option for a custom string (and/or QR code) to specify a particular app version to be used within a group. Upon changing the app version, the client will resolve the source code, download it, and run it with a new instance ID.
Whenever a message is sent, it is added to the app data of the instance in which it was sent. When a new app version is run, the admin has two options:
Import old app data (i.e. the chat log)
Start fresh
If users want to switch from one version to another version... and then back to the original version again, they have two options.
Restore the original conversation (without the most current app data) - the client creates a new instance of the original app version and imports the original app data
Import the new app data to the original app version - the client creates a new instance of the original app version and imports the newer app data
The particular implementation here depends on how far a long the DAO roadmap is at that time of creating this (see #8). If it is still in phase 0, then the client will simply resolve the source code from an IPFS (or optionally HTTPS) link. However, if it is phase 1 then the client will look up the location of the source code on-chain and resolve it from there.
Questions
UI/UX Needed.
What is the best way to determine which app versions to suggest? This depends a lot on what stage other parts of the roadmap are in.
How should app updates work? It should probably be opt-in. All clients need to be on the exact same version, including new entries into a group that users a non-up-to-date version. In order for all clients to be able to resolve this source, it means that they need to share the exact location of the app version they are using through the protocol.
When restoring an original conversation, should the client render it through the app version available at the time or the most up-to-date version of that app?
Crypto wallet integration
Status
Planned
Completed
Description
This feature is dependent on the protocol roadmap (see #4). Crypto should be able to be deposited, withdrawn, and spent on protocol microtransactions in the app. As long as the protocol has laid out the details for how the microtransactions will work, the client can implement the wallet in anticipation of it working. Then, only integrate the micropayments once that feature is operational on the protocol.
Questions
UI/UX Needed.
Should this be moved to phase 2 so that there is not a strong dependence on the protocol roadmap for this phase 1? The reason it is currently included in phase 1 is because it is an important feature that should be prioritized as early as possible.
Phase 2: Advanced Features and Optimizations
Status:Planning
There are a number of enhancements that will take the Concorde client to the next level.
Enhancements
Mobiles apps
Android and iOS will be essential to mainstream adoption. iOS will present a particular challenge do to the restrictiveness of the platform. This will require reimplementing the client from scratch, with a mobile optimized UI/UX—since Electron doesn't run on mobile.
Web
Believe it or not, it is possible to implement the Concorde client on the web. Instead of a WebView, it uses a properly sandboxediframe for the execution environment. The client communicates with the execution environment using postMessage. And general network access is restricted to a single source. This source will be a hosted version of the protocol daemon.
Of course the web version is less trusted than the full client downloaded on the user's machine, however, it is more accessible.
Custom desktop implementation
Electron is a good solution for the desktop app. However, WebKit mightprovide a better foundation than Chromium. Based off of Bun's design, it might also be interesting to build an Electron alternative using Zig + WebKit. This could also potentially then work on Android and perhaps even iOS (depending on App Store rules).
Multiple active apps
When users launch groups, they should be able to load multiple apps simultaneously. For example, imagine that there are a group of friends using Concorde. They might want to chat with each other AND play a game together. There could be an app version that is a game and an app version that is a chat interface. Therefore, instead of switching from one to another, they should just be able to have two apps running side-by-side.
This would indicate that each group should have an app launcher that opens into different app version.
Schema compatibility
The biggest barrier to switching app versions is the message schema. For example, one app version could format messages like this { "message": "gm" } and another could format it like this { "action": "message", "payload": "gm" }. Porting the data from one app version to another would not work.
This is currently handled in the following ways.
The client will only suggest manually approved alternatives to the current app version a group is using. It is assumed that app developers will only add compatible app versions to this list.
If a schema is broken, users are easily able to restore their old session with the old app version.
However, ideally the client could run some automated checks to ensure schema compatibility. App versions could include optional configuration files that formally describe their schema. In doing so, the client can double check to make sure there are no mismatches in expected formatting.
There is also potential to built a "data migration" feature that changes data from one schema to another. With that said, it might be optimal to implement this inside the app version as opposed to building it into the client.
Wallet verification
External crypto wallets should be able to be associated with Concorde public keys. If Concorde is built on Ethereum, it could be implemented with wallet connect.
Token Gating
If externally verified wallets hold certain tokens, such as
NFTs
A minimum balance of fungible tokens
It should be possible to whitelist them into groups. This will have to be implemented in conjunction with the protocol roadmap (#4).
The Graph protocol integration
The Graph allows applications to query on-chain data. This will not leak data because it is querying a decentralized system, and not writing data or pinging the app developer's servers. Therefore, any on-chain data should be able to be pulled into Concorde app versions.
The client should provide a secure API that queries The Graph. This way NFTs, on-chain assets, ENS name, token balances, etc. can all be brought integrated into Concorde apps. For example, if a game is built on Concorde, their username could be their ENS name and they could use their loot or other game-related NFTs.
Private crypto transactions
The client should facilitate crypto transactions between users in groups (i.e. paying someone or sending an NFT). However, this needs to be engineered very carefully. There are many attack vectors in which untrusted app developers could drain crypto wallets or leak user information, if done improperly.
The implications of this need to be explored further. It also might require work on the protocol side (#4). It would be especially great if there was a way to give a small cut of all transactions to the app developer.
Securing and Syncing Local Data
All local data should be encrypted at rest. Secure enclaves should be used when applicable. Local data should also be backed up in a fully E2EE manner. This data should also be transferrable to other devices. Further research needs to be made into best practices here.
Milestones
iOS
Android
Web
Replace Electron
Multiple active apps
Automated schema compatibility checks
Data schema migrations
External wallet verification
Token gating
The Graph integration
Private crypto transactions
Encrypting local data
Device syncing
Questions
UX needed for mobile apps and web.
What constraints will the App Store rules create for the iOS app? It may need to use a more centralized approach, similar to the web. It also might violate rules to have a directory of apps that can be arbitrarily launched. Lastly, it may not be possible to bundle a custom version of WebKit, if that is something we opt to do.
What would be the best way to validate and migrate schemas such that it is easy for developer to configure?
How do the external and internal wallets integrate? Concorde probably shouldn't compete as a wallet, but it needs to be able to make transactions on behalf of the user in order to pay microtransactions.
How should token gating be implemented?
Is there a way to integrate with The Graph without requiring users to have any $GRT?
Full specs for private crypto transactions are needed. This is a very important feature.
What are the best practices for protecting local data?
Should syncing be cloud based or P2P (from old device to new device like Signal)?
What data storage concerns are there? How can these be addressed? This is very important since the amount of data stored on the device could get quite high.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Objective
Competing versions of Concorde's UI and business logic ("app versions") must execute in an environment that provides the minimal infrastructure that enables developers to easily build and effectively fork multiplayer applications.
The client is responsible for securely running app versions and storing user data, such as private keys, contact lists, and group chat logs.
Tenets
Trust
On the modern web, everyone must treat each other like adversaries. The app developer assumes that all users are a potential threat. The users are wary of executing code provided by the app developer and do not trust the app developer with their data. Furthermore, users are often skeptical of each other. For example, a user may trust their friend on Twitter, but doesn't trust a user they don't know.
This makes running developing a web app like operating a business in a war zone. It creates overhead and inhibits activity. It also has a major implications for forking.
By forcing all network connectivity to go through a E2EE messaging protocol, it means that users only must trust other members of their group. Assuming they trust the Concorde protocol, they can then switch between many different app versions without concern. Furthermore, developers can collaborate freely since the Concorde protocol is designed with great care to prevent data leak attack vectors.
The web browser is the best app
The web browser is the most useful app on your computer. It has so much functionality and the amount of things you can do on it grows exponentially over time. This is because it provides two things:
Web browser developers didn't build this amazing functionality. They simply created an environment for this type of functionality to evolve. They harnessed a market to build out its functionality.
The metaverse is a messaging app
Roughly speaking, the metaverse is a collection of virtual worlds that people can jump between. They can go to different locations with their friends and do different things socially.
Technically speaking, a given virtual world within the metaverse is custom frontend for a group chat. Let's say you are in a virtual space. If you update your position, you will need to notify all other people in that space of your change in position. In doing so, you are essentially sending a "message" to them telling them that you have moved.
Concorde is a group chat with an evolving frontend. The web browser is capable of rendering AAA graphics and can even power VR experiences. Using web browser technology on the frontend and a secure, private, decentralized messaging protocol on that backend, Concorde is essentially a metaverse play.
This is especially exciting when you consider the fact that these metaverse worlds are analogous to "app versions" inside of Concorde and can improve exponentially over time (for more information on how this would work, see #8).
Local-first software
Kleppmann et al. have written the definitive argument for local-first software. According to the authors, local-first software has the following ideals and benefits:
When applying this rubric to a variety of apps, they come up with following rubric
Concorde is an opinionated operating system for local-first software.
This is because Concorde is intended to be a high-performance syncing layer for append-only logs with an execution environment for frontends using this data model. These logs can contain CRDTs that enable the full suite of local first software benefits
What is beautiful about the messaging app use case is that much functionality can work according to these local-first ideals without even needing CRDTs (but can use them in order to build more complex user experiences). And by utilizing FRP, this makes the developer experience really nice.
Plan and Questions
Concorde is a messaging app. Users congregate in groups and send messages to each other through a decentralized protocol (see #4). What makes Concorde unique is how it handles message data.
Concorde allows groups to install custom frontends that determine how messages within a group are sent and interpreted. These custom frontends are also known as app versions, because they are all different versions of the same group chat experience built by competing teams of developers. For the sake of brevity, these different app versions may be referred to simply as apps.
Let's say two users want to chat. One will first invite the other to a group.
Next, they will decide which app version they want to use within this group. We will call the one they choose "App 1".
When they use an app version, they download its full source code. This ensures that all apps in the ecosystem are open source and forkable.
After the code is downloaded, it is executed in a secure environment (WebView) that is prevented from accessing the Internet
When a user takes an action in the app, they let other users in the group know by sending them an encrypted message using the protocol (see #4).
So where does the client fit into this system? The client is the application running on the user's device that connects to the protocol and provides the environment for the different app versions to execute. You can think of it as a thin shell that wraps around the app version to provide the minimal infrastructure to make Concorde possible.
To illustrate, let's walk through one more example—this time with more detail about the client's role.
Using the client's UI, one user will invite another to a group. Once they are in a group, the two clients will initiate a connection to each other using the protocol and download the same app version. There will be a default app version that can be changed in the group admin's client UI. Again, we will call this app version "App 1".
Before any messages have been sent in the group, it will probably be a blank screen. In reality, it may look different. It depends on how the developers implemented the app version being used. For the sake of this example, imagine it looks like this.
Then let's say that User 1 types the message "gm" and clicks the "send" button in the UI. This will call a hook in the WebView that tells the client to send a message over the protocol letting User 2 know that User 1 said "gm". Technically speaking, this message might look like the following:
{ "action": "message", "payload": { "id": 1, "body": "gm" } }
. With that said, developers of "App 1" are in full control of the message schema, how messages are constructed, and when messages are sent.Once this message is sent over the protocol, the clients store it locally. They then update the state of the frontend by triggering an event inside the WebView, delivering the message to the app.
A similar process happens when User 2 "hearts" User 1's message:
{ "action": "react", "payload": { "targetId": 1, "emoji": ":heart:" } }
Now let's imagine that User 1 changes the app version to "App 2". This new custom frontend will take the old state and render it differently. It also may have different rules for how sends new messages to generate new state.
The client will do this by downloading the new source code, opening it in the WebView, and retrieving the old message log from local storage and it as them as the initial state for the app inside of the WebView.
In summary, the full list of high-level client responsibilities are as follows. The client...
Phase 0: Single Purpose
Status: In Progress
The purpose of this phase is to enable developers to get started and build the app execution environment. During this phase, Concorde will only support a single, global group for all users. All users will be running the same app version. However, developers will be able to launch into their own groups and app versions for testing purposes (however, this will be a part of #7). The client will be built using Electron for desktop users only.
Components
Execution environment
The default app version ("the app") will be initially bundled with the Concorde binary. The the app will load in a WebView (the standard Electron renderer). It should be set to disallow network requests.
Protocol integration
Upon initially opening Concorde, public/private key will be generated for the user and these will be used to interact with the protocol (see #4).
When an action takes place, an
emit-message
IPC event will be triggered in the renderer and will be read by the main process and passed to the protocol as a message.When the protocol receives a message, the main process will send it into the renderer as a
receive-message
event.In order to connect to the protocol, the main process will start a daemon that maintains a connection in the background and communicates with the main process to pass messages to and from the renderer. When a message is sent or received, the daemon will add the new message to a chat log file. When the client initially starts, it will take the contents of this file and inject it using contextBridge inside a preload script setting it to
window._concordeInitialState
.Milestones
Questions
Phase 1: Full UI
Status: Planning
Once phase 0 is complete, the app will be usable and developers will be able to begin iterating on the frontend. However, the possibilities will be severely limited. Phase 1 is intended to bring the full suite of client features to Concorde. This includes the following components.
There is a large amount of ambiguity here because this is dependent on UI designs and product planning. If anyone wants to wifeframe and prototype the UX, it would be greatly appreciated. As a result of this ambiguity, this section will be laid out slightly differently.
Contacts
Status
Description
Users will be able to add other contacts based on their public key (QR code or string). They will also be able to set a preferred name for that contact. In conjunction, users will be able to set the preferred name for themselves that will serve as the default contact name in other's "contact book".
Contacts will be stored locally in a directory and will be able to be edited and removed. When starting a new group chat, users will be able to type out contacts' names and send invitations with autocompletion.
Questions
Creating, joining, and managing one or more groups
Status
Description
Users should be able to create groups and set the group name. If the user has created the group, they will be considered the "admin" and will therefore be able to select which version of the app is running in the group (see below). Admins will be able to set and remove other members as admins, but the founding admin cannot be removed by other admins. The founding admin must resign (and cannot do so if there are no other admins. This process will be facilitated by the protocol (see #4).
The following are called "exit events":
In both of exit event cases, users that automatically switch over ignore the old group and the old data is brought over to the new group.
Invitations must be opt-in. You can use the protocol to construct a group with any set of members, if you know their public key. However, that only whitelists them into the group. The client will ignore the existence of such groups until the user opts-in by accepting an invitation or automatically joining due to an exit event.
Moderation tools (such as hiding messages) will be implemented by the app version developers and not the client.
There will also be a user interface with a list of group chat so the user can open into different groups. Selecting a group opens up the app version inside a renderer window. The list will have some sort of indication if there is new activity in the group.
Questions
Changing app versions within groups
Status
Description
Under the hood, Concorde allows groups to run multiple app versions at once. However, at this phase there is only 1 active app version at a time. Apps running inside of groups have three properties:
The client will provide a directory of suggested app versions as well as an option for a custom string (and/or QR code) to specify a particular app version to be used within a group. Upon changing the app version, the client will resolve the source code, download it, and run it with a new instance ID.
Whenever a message is sent, it is added to the app data of the instance in which it was sent. When a new app version is run, the admin has two options:
If users want to switch from one version to another version... and then back to the original version again, they have two options.
The particular implementation here depends on how far a long the DAO roadmap is at that time of creating this (see #8). If it is still in phase 0, then the client will simply resolve the source code from an IPFS (or optionally HTTPS) link. However, if it is phase 1 then the client will look up the location of the source code on-chain and resolve it from there.
Questions
Crypto wallet integration
Status
Description
This feature is dependent on the protocol roadmap (see #4). Crypto should be able to be deposited, withdrawn, and spent on protocol microtransactions in the app. As long as the protocol has laid out the details for how the microtransactions will work, the client can implement the wallet in anticipation of it working. Then, only integrate the micropayments once that feature is operational on the protocol.
Questions
Phase 2: Advanced Features and Optimizations
Status: Planning
There are a number of enhancements that will take the Concorde client to the next level.
Enhancements
Mobiles apps
Android and iOS will be essential to mainstream adoption. iOS will present a particular challenge do to the restrictiveness of the platform. This will require reimplementing the client from scratch, with a mobile optimized UI/UX—since Electron doesn't run on mobile.
Web
Believe it or not, it is possible to implement the Concorde client on the web. Instead of a WebView, it uses a properly sandboxed
iframe
for the execution environment. The client communicates with the execution environment using postMessage. And general network access is restricted to a single source. This source will be a hosted version of the protocol daemon.Of course the web version is less trusted than the full client downloaded on the user's machine, however, it is more accessible.
Custom desktop implementation
Electron is a good solution for the desktop app. However, WebKit might provide a better foundation than Chromium. Based off of Bun's design, it might also be interesting to build an Electron alternative using Zig + WebKit. This could also potentially then work on Android and perhaps even iOS (depending on App Store rules).
Multiple active apps
When users launch groups, they should be able to load multiple apps simultaneously. For example, imagine that there are a group of friends using Concorde. They might want to chat with each other AND play a game together. There could be an app version that is a game and an app version that is a chat interface. Therefore, instead of switching from one to another, they should just be able to have two apps running side-by-side.
This would indicate that each group should have an app launcher that opens into different app version.
Schema compatibility
The biggest barrier to switching app versions is the message schema. For example, one app version could format messages like this
{ "message": "gm" }
and another could format it like this{ "action": "message", "payload": "gm" }
. Porting the data from one app version to another would not work.This is currently handled in the following ways.
However, ideally the client could run some automated checks to ensure schema compatibility. App versions could include optional configuration files that formally describe their schema. In doing so, the client can double check to make sure there are no mismatches in expected formatting.
There is also potential to built a "data migration" feature that changes data from one schema to another. With that said, it might be optimal to implement this inside the app version as opposed to building it into the client.
Wallet verification
External crypto wallets should be able to be associated with Concorde public keys. If Concorde is built on Ethereum, it could be implemented with wallet connect.
Token Gating
If externally verified wallets hold certain tokens, such as
It should be possible to whitelist them into groups. This will have to be implemented in conjunction with the protocol roadmap (#4).
The Graph protocol integration
The Graph allows applications to query on-chain data. This will not leak data because it is querying a decentralized system, and not writing data or pinging the app developer's servers. Therefore, any on-chain data should be able to be pulled into Concorde app versions.
The client should provide a secure API that queries The Graph. This way NFTs, on-chain assets, ENS name, token balances, etc. can all be brought integrated into Concorde apps. For example, if a game is built on Concorde, their username could be their ENS name and they could use their loot or other game-related NFTs.
Private crypto transactions
The client should facilitate crypto transactions between users in groups (i.e. paying someone or sending an NFT). However, this needs to be engineered very carefully. There are many attack vectors in which untrusted app developers could drain crypto wallets or leak user information, if done improperly.
The implications of this need to be explored further. It also might require work on the protocol side (#4). It would be especially great if there was a way to give a small cut of all transactions to the app developer.
Securing and Syncing Local Data
All local data should be encrypted at rest. Secure enclaves should be used when applicable. Local data should also be backed up in a fully E2EE manner. This data should also be transferrable to other devices. Further research needs to be made into best practices here.
Milestones
Questions
Beta Was this translation helpful? Give feedback.
All reactions