i think the test script that's running has to run with the --coverage flag

https://github.com/ZbayApp/waggle/runs/3115648660?check_suite_focus=true

zbaylite should too!

channel saga should be shared. This part of store is responsible for keeping information about unread messages, keeps an input value etc

We should validate that data written to the user table meets our criteria, and show an aggressive warning if it does not.

1. All users should validate that username entries are correct, by the same criteria as the registrar frontend (alphanumeric, character limits, etc.)
2. All users should validate that there are not duplicate username registrations.
3. Seeing a message from a user with a duplicate registration signed by the admin should trigger a warning, even if there is only one registration in the user table. This does not apply to unregistered users, or an unregistered user having the same name of a registered user. This aggressive warning should only show when we have two messages from registered users signed by different public keys with the same name.
4. The warning should show on startup or, in the future, whenever someone switches to the community.
5. The warning should include a "leave community" button.

https://www.figma.com/file/TV9pF84Ob8pLYRLu83gNol/Joining-when-owner-is-offline?type=design&node-id=311-6979&mode=design&t=eS9WDLYpQNod1Acl-4

Since we're actively dogfooding an internal testing version, and since we're focusing more on testing right now than QA, let's do automatic updates for every change that gets pushed to the develop branch.

This will also encourage folks to really try to catch any issues with tests before merging.

@vinkabuki knows of some errors that we are not currently catching.

The instructions within the application said that it should take a bit less than an hour, and to more securely anchor the installation I should click to restart it and then everything should be optimum.

OS = Win 10/64
Zbay version (unable to check, but installed about two hours ago).

I installed Zbay. I take my time reading and looking over, and noting that it didn't say 'beta' anywhere decided to set it up and give it a try.

I couldn't find anywhere to set it to use TOR by default for private messages, and read where it suggested closing and relaunching to achieve I guess, maximum entropy?

Anyway, when I clicked to let it close and reopen I got errors which it wanted to send to the dev team, and then locked me out. It won't successfully launch at all now, and keeps coming up with the error which I grant access for it to report.

I did not fund it, although I was ready to right after that reboot. At this point it looks like I'll need to uninstall and reinstall but nowhere did I see a place to restore using my private paper recovery phrases.

waggle:libp2p:err Could not connect to discovered peer QmV1D4RtapSnCfBbahhkApPwK4WiDqMJS3BcEjXz9GZv7S AggregateError:
Error: Hostname/IP does not match certificate's altnames: Host: dtwy5lwyzf3we6jnjq72nsyqkfw27bibvrfheshxydbcbyy7u6tpf6ad.onion. is not cert's CN: hbq5s7o6omo6raevbhkl6rqlut5dzdzzhohg57veesq2opin4ccoioid.onion
at Array.map ()
at maybeSettle (/home/bart/Code/zbay/nectar/node_modules/p-some/index.js:31:11)
at /home/bart/Code/zbay/nectar/node_modules/p-some/index.js:69:23
at maybeSettle (/home/bart/Code/zbay/nectar/node_modules/p-some/index.js:31:11)
at /home/bart/Code/zbay/nectar/node_modules/p-some/index.js:69:23
at processTicksAndRejections (internal/process/task_queues.js:93:5) {
name: 'AggregateError'
} +0ms

User should be able to send and receive DMs.

• owner of root key should control the CRL list
• CRL should be either a seperate channel or a different kind of message on "user certficate channels" (whichever seems more convenient)
• CRL should be respected in WebsocketOverTor.
• • if either server or client certificate is on CRL the connection handshake should not succeed
• • mind that CRL can be update after we have started listening (on websocket) and we need to also respect changes made since than
• certificates should be disregarded from CRL when they are passed their expiration date (NotAfter field)
• when certificate is added to CRL, each connected peer should actively disconnect from it (check peerId of connections it has and hang up connection if connected to the peer being expelled)

steps to reproduce:

1. post a link
2. click on it.

Right now we don't have any setup for doing tests to catch visual or CSS regressions.

Here are some approaches:

• https://github.com/mapbox/pixelmatch
• https://blog.logrocket.com/automated-visual-regression-testing-with-jest/

Let's pick one of these and use it religiously whenever we're doing CSS changes or fixing CSS regressions.

Any user should be able to do this. In the future we might limit it to channel owners or add limits on the number of channels someone can add.

Channel names should have the same validation rules as usernames.

whitelist logic should be shared

note that images and files will need to be encrypted once we take this step.

Right now user registration can take 20 or 30 seconds or more sometimes.

From Emi:

"I noticed that sometimes user registration takes a long time. I think this is happening because before saving cert to db we iterate over certificates and parse them to check if username exists. Worst case scenario we iterate to the end of log-db. I saw in the logs that this can take a while."

We should figure out what the issue is. It should be almost instantaneous, no?

steps:

1. @ mention someone

expected:

1. user selector appears with autocomplete
2. name is highlighted for sender
3. name is highlighted for recipients
4. user gets a notification of the mention on desktop or mobile
5. in notification settings you can choose to be notified only of @ mentions and DMs.

Steps to reproduce:

1. Start a DM
2. Click "..." button in top right, then > Remove > Yes

Expected: DM thread is removed from UI
Actual: It is not removed. And clicking the "..." button again immediately shows the remove dialog, so there's some strange state getting set.

Emi had two Zbays running, one running release candidate in a docker and one running develop branch locally.

The local one could not see messages from the docker one. Other Zbay users could see messages from both.

Theories about why this was happening:

One hypothesis: local was not connected to docker directly and messages aren't propagating correctly across peers who aren't directly connected.

I'm not sure how hard this is to reproduce, but it probably will take a few tries. We might just need to write a lot of tests that vary when peers come on and offline, and who is connected to whom.

Right now it takes about 23 seconds before a first-time user reaches the registration screen.

This feels too long. In the logs, it looks like the step where the user registration screen displays is:

subscribeForAllConversations: 0.018ms
Sending back 2 certificates
initAllConversations: 19.686ms
Message replicated
Sending back 4 certificates

...so the user is syncing even before the user registration screen displays? Why not display it right away on app startup?

Do we even need to be connected to the network to show the user registration screen? The user can take their time choosing a name, and we can spin up Tor etc while they're doing that.

Then they just need to connect to the registrar via Tor right?

In the model we're moving towards, they won't even know which network they're connecting to when the app starts. They'll paste in an invite link or start their own network. We can still start a Tor hidden service and libp2p though, while we wait for them to decide.

This is important because I'm already seeing latency return in v21.

Hi, just launched Zbay Lite. Great work!

rambling story with UX paper cuts

After launching Zbay Lite for the first time, it asks for a name I'd like to register, and I entered zecnate. So far so good.

The main screen appears and I start exploring it. Then I realize up at the top it says @anon<NNN>, and I think "huh, but I thought I registered a name". I click that, see an option to register, then go to do so. I re-enter the same name, and it mentions I need to add funds.

I go to add funds, I get a zaddr. I can't find the QR Code button for the zaddr. Why isn't there one? (Aside: why is the shielded address second and hidden behind a drop-down?) I use a commandline tool to generate a QR code then send some funds to that address.

It takes Zbay a while to show the pending funds. (This doesn't surprise me, but I figure it would confuse non-blockchain-savvy users.)

However, over the next while, the pop-out over the "add funds" button keeps appearing prompting me to add funds. But I've already done so, I'm just waiting for them to confirm.

After a while I see my name registration appear in the #zbay channel. Yay!

However, now I can't post to that channel. In fact, sometimes I see a text input widget, and sometimes I do not. I've typed text into the widget, but I can't hit enter and there's no send button.

I try creating a new channel and I'm able to do so after a few tries. After that, it looks like my balance is pending again.

Generalization of the Issues

Generally it seems like I need to try actions a few times and the response is inconsistent depending on sync state or confirmation of transfers. Whenever something is pending, I can easily get confused because when I try an action I don't see an immediate response.

Follow up

I apologize for jumbling together multiple issues in a rambling story, just trying to get this all down on paper. If you'd like to suggest specific tests I can run those, and potentially file separate tickets for separate more precise issues.

UX brainstorms

It might be helpful to have a "pending actions" widget that shows a queue. Example:

[cute yet unobtrusive spinner...]
1. registering `@zecnate` - status: waiting for transaction confirmation.
2. create channel `#zcash-dev` - status: waiting for funds.

It might also be nice to have a separate "busy indicator" whenever we're waiting for zecwallet-lite to do some operation.

Keep up the good work! I hope I can ditch slack sooner or later. :-D

Right now, any member of the community can add arbitrary entries to any orbitdb, including the user table, the channel list, DM threads that don't belong to them, etc.

We should add orbitdb access control to confirm that users can only edit the databases in ways that are intended, and that all other edits are ignored by other peers.

Examples:

1. User table should only be writable by owner (this does not require a custom access controller, I don't think)
2. Only owner should be able to delete channels. Users should be able to add channels but not delete them.
3. Users should not be able to add invalid data to the channel list.
4. Only the participants of a DM thread should be able to write messages to that thread. (This might not need custom access control either)
5. Users should not be able to write invalid messages to any channel.
6. There should be a size limit on messages.
7. The owner should not be able to add invalid data to the user table.

Question: are there any other tables I'm forgetting about here?

• Correct typo in "MentionPoper"

Right now we suspect that delivering a snapshot to a user speeds up the syncing process, but we don't know if this is true, or by how much.

We should find out how much making a snapshot on request for a new user and delivering it to the user speeds up initial message sync.

to be clear we are measuring snapshot creation time plus time to send and parse snapshot, not just the latter.

It's potentially okay if snapshots are partially working, since if they speed things up while partially working we can assume they speed things up even more when working completely.

We should compare create snapshot + sync from snapshot to regular syncing in the latest (master) orbitdb.

Right now you can accidentally release new code with the same version number as an existing release.

We should update CI so that this is impossible. CI should fail if the version number is the same as existing.

https://docs.google.com/document/d/1cjx3wEWvOSnZUXazZirGpttS1Bt6ajTSxnqmr5LXqVg/edit

Right now, we trust that the registrar is honest and doesn't impersonate people, or let two users register the same username.

If we ever see two users with the same username, we should:

1. Show a full-screen warning to the user who sees this. The message should continue to display in some way when the user closes their screen.

2. Broadcast a message containing the proof of equivocation to all other users to be sure everyone sees the equivocation, e.g. in the case the message was sent in a DM or on a private channel such that it would not be visible to all participants. We should make sure there is a way to do this without sharing message contents.

This behavior should work on desktop and mobile, and it's critical, so at least some of it should be shared code.

(We've talked about breaking out the encryption and identity bits of waggle into a shared library.)

This ticket shouldn't be closed until there's a corresponding ticket created for implementing this in ZbayMobile

Store state was incorrectly mocked in app restarting test (corrected in commit TryQuiet/ZbayLite@a0ff78f)

There are still missing assertions related to loading panel in mentioned tests scenarios.

They're missing cases that checks against changing socket's 'isConnected' prop

https://docs.google.com/document/d/10ClqwCFw0a7ceW9i9iIy8f8-XiBEwCLNd6h20RNEYgI/edit

In Zbay we had a notification that a user had been added to a community. In Quiet we should add this back.

Two options (I think #2 is the right choice because it's so simple, but it's not the best)

1. We could do it the way we did it before, where there was a special kind of message that displayed in the channel (should be #general i think) when we see that a new user has been added. This would appear as coming from a "bot" called "Quiet" with the Quiet logo, and we could use it for other meta level messages.

2. We could have the owner/registrar send the message "@username joined community-name" to the #general channel after they complete the process of adding that user. We do something like this already for new channel creation.

The second is less good because the owner can spoof that message just by typing it, even when they did not add a user. But it's also really simple. And it reinforces that the owner is the one responsible for adding people.

Steps to reproduce:

1. Click on a username in #zbay channel

Expected: can click button in modal to DM.
Actual: it is inactive / grayed out, even though the user is registered

ChannelInputComponent takes [{ nickname: string }] as 'users' param in order to display mentions by typing in '@'.
There is a need to get list of channel participants, e.g. by combining peerList (community) with certificatesMapping and pass it to the component

We knew that libp2p is trying to reconnect in case of failed connections, but there is at least one tor problem that does not disappear itself.

https://www.reddit.com/r/TOR/comments/a1vyxt/closed_1_streams_for_service_scrubbedonion_for/

waggle:tor Nov 16 10:01:40.000 [notice] Closed 1 streams for service [scrubbed].onion for reason resolve failed. Fetch status: No more HSDir available to query.
waggle:tor +15s
waggle:tor Nov 16 10:01:56.000 [notice] Closed 1 streams for service [scrubbed].onion for reason resolve failed. Fetch status: No more HSDir available to query.
waggle:tor +16s
waggle:tor Nov 16 10:02:12.000 [notice] Closed 1 streams for service [scrubbed].onion for reason resolve failed. Fetch status: No more HSDir available to query.
waggle:tor +17s
waggle:tor Nov 16 10:02:27.000 [notice] Closed 1 streams for service [scrubbed].onion for reason resolve failed. Fetch status: No more HSDir available to query.
waggle:tor +15s
waggle:tor Nov 16 10:02:44.000 [notice] Closed 1 streams for service [scrubbed].onion for reason resolve failed. Fetch status: No more HSDir available to query.
waggle:tor +16s
waggle:tor Nov 16 10:02:58.000 [notice] Closed 1 streams for service [scrubbed].onion for reason resolve failed. Fetch status: No more HSDir available to query.
waggle:tor +14s

Options for fixing:

1. Make an installer that we sign by hand and update rarely that downloads the latest version.
2. Automate the EV signing process using a HSM and some bureaucratic process. See: vcsjones/AzureSignTool#112

The latter is better so we should try that first

A user with Apple Silicon is reporting high CPU usage for both Zbay and Tor.

This is expected, according to Electron folks: https://www.electronjs.org/blog/apple-silicon

We can build an arm64 version of Zbay, and then we can make a universal binary (both versions stuck together) using this: https://github.com/electron/universal

I think we should do this soon given that performance issues are something we really need to stamp out, and given that many users will have recent macs.

It would be great to have performance tests run in CI on Apple M1 hardware.

Also, see: electron/electron#26710 for some possibly helpful information about electron-builder not being the officially supported tool. They recommend electron-forge.

Tests passing:

• user can send an encrypted DM
• user can receive an encrypted DM
• username displayed is correct
• other users cannot send a DM as this user or trigger a DM notification.

Look at this build: it consumed 6 hours of CI time, because its the default timeout. Set this to something that makes sense.

https://docs.google.com/document/d/1S25Mwk2wfX4A-ZTsGfgR2653HjUJoS_pgEKCQ0U2FRw/edit#

Right now we're signing certificates with the root CA. Standard practice is to keep the root CA online as little as possible and sign with an intermediate CA. We should do this.

Owner should be able to:

1. Back up the community CA (which is subsequently forgotten on the device) with a seed phrase.
2. Restore this backup, revoking their old intermediate CA, and re-signing user certificates one by one, or re-inviting people (How will this work?)
3. Be the owner of the community again.