Deleplace
Repos
56
Followers
73
Following
5

A collection of good snippets, in a lot of languages

107
7

A quick mobile-to-desktop share capability, through matrix barcode

Source code to illustrate articles

Events

opened issue
Prefetch race condition: resource downloaded twice

When:

  • a client C receives a pre-cast and starts prefetching resource R,
  • then receives the cast signal, before R is finished prefetching,
  • the resource R is downloaded twice
  • (to be verified) R is not displayed until the second download is finished, which most often arrives latest

Please consider:

  • acknowledging that a prefetch is already happening, and joining on it

Note that R has a different URL at pre-cast time (/prefetch...) and at cast time (/f/..., or https://storage.googleapi.com/...), for polling reasons.

Created at 3 hours ago
issue comment
Multiple resources downloaded twice

The react-progressive-image project has been archived (not maintained anymore, not updated for years). Also, progressive rendering with placeholder is not really worth it for encrypted pictures that need to be fully downloaded before decryption. Better get rid of the react-progressive-image dependency.

Created at 21 hours ago
opened issue
Multiple share: missing E2EE mention

When sharing 1 picture from Android, we see 2 messages "Resized to 1200x1600" and "Was end-to-end encrypted".

When sharing several pictures from Android, we only see the "Resized to 1200x1600" message.

Created at 21 hours ago
opened issue
Multiple share: thumbnails not displayed

When sharing several encrypted photos from Android:

  • Mobile uploads encrypted images
  • User scans
  • Mobile sends dispatch requests with attached thumbs
  • Target receives the thumbs but does not display them
  • Then later, the images are downloaded, decrypted, and displayed

Please make sure to display the thumbnails.

The problem is easier to reproduce when throttling the internet bandwidth of the target browser.

Created at 22 hours ago
issue comment
Multiple resources downloaded twice

While downloading twice is bad for bandwidth in general, it's not sure that the 2nd download is used at all or is blocking anything.

Created at 22 hours ago
issue comment
Multiple resources downloaded twice

This does not happen when sharing a single image...

Created at 22 hours ago
issue comment
Installations from gopkg.in failing

I experienced it too yesterday, during roughly 5 hours. Then it worked again.

Created at 22 hours ago
opened issue
Multiple resources downloaded twice

It seems that image resources of a multiple share action are downloaded twice.

image

The 2nd download is initiated by dist.js of react-progressive-image. It stalls (grey) until the 1st download has finished, then it launches.

Created at 23 hours ago
issue comment
After prefetch: work during 150ms thumb animation

The problem occurs after prefetch but not really after a normal cast, as the 150ms thumb animation starts at the same time as encrypted resource download, which takes times.

Created at 23 hours ago
opened issue
After prefetch: work during 150s thumb animation

Current behavior

  • Resource R is pre-cast
  • Resource R is prefetched
  • User scans
  • Thumb animation show up for 150ms
  • Then the decryption happens (can take some time if the file is large)
  • Then the decrypted resource R is displayed

Current behavior

  • Thumb animation and decryption start at the same time
  • R is displayed up to 150ms sooner
Created at 23 hours ago
issue comment
Early encrypted download: on page refresh

#520 would be more general and powerful, but #521 would still be better than nothing

Created at 1 day ago
issue comment
Early encrypted download heuristic (multiple share)

Note that the client is listening to pre-cast signals only when displaying the QR-code, for now (not when displaying the result of the previous share action). See #520, #521.

Created at 1 day ago
issue comment
Early encrypted download heuristic (single share)

Note that the client is listening to pre-cast signals only when displaying the QR-code, for now (not when displaying the result of the previous share action). See #520, #521.

Created at 1 day ago
opened issue
Early encrypted download: on page refresh

Current behavior

  • Mobile M shares resource R1 with client C
  • C displays R1
  • M starts sharing another resource R2, but C is not listening yet
  • The user refreshes (clears) the page on C, displaying a new QR code
  • No data is fetched by C until the user scans

Desired behavior

  • Mobile M shares resource R1 with client C
  • C displays R1
  • M starts sharing another resource R2, but C is not listening yet
  • The user refreshes (clears) the page on C, displaying a new QR code
  • The backend detects that C is a fine candidate for R2, so it decides to precast R2 to C
Created at 1 day ago
opened issue
Early encrypted download: listen even when no QR code is displayed

Current behavior

  • Mobile M shares resource R1 with client C
  • C displays R1
  • M starts sharing another resource R2, but C is not listening yet
  • The user refreshes (clears) the page on C, displaying a new QR code
  • No data is fetched by C until the user scans

Desired behavior

  • Mobile M shares resource R1 with client C
  • C displays R1
  • M starts sharing another resource R2
  • C is listening and receives the pre-cast for R2
Created at 1 day ago
opened issue
Early encrypted download: on web page refresh

Current behavior

  • Mobile M shares resource R1 with client C
  • C displays R1
  • M starts sharing another resource R2, but C is not listening yet
  • The user refreshes (clears) the page on C, displaying a new QR code
  • No data is fetched by C until the user scans

Desired behavior

  • Mobile M shares resource R1 with client C
  • C displays R1
  • M starts sharing another resource R2, but C is not listening yet
  • The user refreshes (clears) the page on C, displaying a new QR code
  • The backend detects that C is a fine candidate for R2, so it decides to precast R2 to C
Created at 1 day ago
closed issue
Early encrypted download heuristic (multiple share)

IF the following conditions are met :

  • mobile X is uploading (or has finished uploading) multiple encrypted resources R*, and hasn't scanned QR yet,
  • a client Y is currently open and listening to a channel C,
  • we think there is high probability that X will scan Y (e.g. because it has already scanned Y 2mn ago)

THEN Y may start downloading the encrypted resources R*.

This will speed up the subsequent "download" step when X does scan Y.

This is a backend & client concern, the mobile apps (Android and iOS) probably don't need to care at all about it.

Created at 1 day ago
issue comment
Early encrypted download heuristic (multiple share)

See also #60 and #94

Created at 1 day ago
closed issue
Early encrypted download heuristic (single share)

IF the following conditions are met :

  • mobile X has uploaded a single encrypted resource R, and hasn't scanned QR yet,
  • a client Y is currently open and listening to a channel C,
  • we think there is high probability that X will scan Y (e.g. because it has already scanned Y 2mn ago)

THEN Y may start downloading the encrypted resource R.

This will speed up the subsequent "download" step when X does scan Y, typically shaving 300ms for a small (resized) photo.

This is a backend & client concern, the mobile apps (Android and iOS) probably don't need to care at all about it.

Created at 1 day ago
opened issue
Larger downscaled images: 1500x2000 (iOS)

Current behavior

  • By default, pictures > 500kB get resized by the mobile source to 1200x1600 (or smaller depending on aspect ratio)
  • They end up ~250kB-300kB on average (on iOS)

Desired behavior

  • By default, resize them to 1500x2000 instead
  • Make sure the result file size is reasonable, and the upload times not too large as a consequence
Created at 2 days ago
opened issue
Larger downscaled images: 1500x2000 (Android)

Current behavior

  • By default, pictures > 500kB get resized by the mobile source to 1200x1600 (or smaller depending on aspect ratio)
  • They end up ~230kB on average (on Android)

Desired behavior

  • By default, resize them to 1500x2000 instead
  • Make sure the result file size is reasonable, and the upload times not too large as a consequence
Created at 2 days ago

Bound check elimination.

Created at 1 week ago

Dark mode comments popover: border, no shadow.

issues/223 On keyboard shortcut 'R', roll the die.

issues/229 Adjust lang logo for dark theme.

Changed assets.

Created at 1 week ago
Language logos: dark theme

Black on dark background is hard to see

Please provide an alternative (light) version for the dark theme

Created at 1 week ago
Language logos: dark theme

In the Cheatsheet page:

@media (prefers-color-scheme: dark) {
    table.cheatsheet-lines th img.logo {
        filter: drop-shadow(1px 1px #DDD);
    }
}
Created at 1 week ago
issue comment
Early encrypted download heuristic (multiple share)

See also #60 and #94

Created at 1 week ago
issue comment
Early encrypted download heuristic (multiple share)

For a single resource share action, see #514

Created at 1 week ago
issue comment
Early encrypted download heuristic (single share)

For a multiple share action, see #515

Created at 1 week ago
issue comment
Early encrypted download heuristic (multiple share)

It is technically possible to have several clients Y download the same resources early, if they all have a high enough probability to become the target. Only zero or one of them will be scanned in the end, in current action.

There is a cost (for the user, and for the cloud project) associated with downloading data that we're not sure to use. Consider limiting the number of MB eligible to early download, e.g. 20MB.

Created at 1 week ago