blenderskool / blaze Goto Github PK

Logo, favicon, etc. should be created for proper branding of the project.

Even though rooms are meant to be easy to remember, a share link can be added for extra convenience to invite other peers to join the same room.

This option can be added at the right side of the header (which currently shows a fake element to accommodate spacing)
Will make use of Web Share API and option would show up only on browsers that support this API

This sounds a little weird, but when the browser decides to close the file-sharing connection (mostly WebRTC) in the background, the UI does not reflect the changes and still shows the user connected.
Further file transfers do not work until the user reconnects.

Blaze is built for sharing files across multiple peers in a blazing-fast way. While the current logo mainly featured a cloud with a lightning symbol, it did not capture the true identity of Blaze.

New logo proposal

The new logo tries to improve upon the current logo of Blaze by retaining the original colors and the lightning symbol.

• The cloud is dropped completely as Blaze is primarily meant to be a peer-to-peer tool and keep very minimal dependency on central server. For the file sharing case, a cloud may have an incorrect perception as a cloud storage solution(which Blaze isn't)

• The lightning symbol is now the primary part of the logo as it correctly captures the speed and ease of use Blaze tries to achieve. The design of the lightning symbol is updated to look similar to the zap emoji ⚡ which is mostly used for referencing Blaze in articles and posts.

• Small dots have been added on the lightning symbol to indicate peers connected to each other. The lightning here can also be interpreted as a medium to connect peers with each other.

• The text gets a new look from the Jost font family. This font change was recently made on the app.

Logo with the text

Logo as an app icon

Logo on installed PWA

Issue sending multiple files between Android and Linux on Firefox. Operation ends up stalling.

Firefox on Linux shows an active WebSocket connection, whereas Android shows WebRTC.

On batch select and send from Android , the files seem to get overlapped, which result in no transmission.

A settings page can be used to allow to edit nicknames and other details of the client.

Server in production logs the users joining in the room. It is useful in debugging purposes and must be removed in production.

Socket.io is currently handling both WebSocket and WebRTC connections. While it serves the purpose, it has a few downsides which are making me consider this decision:

• WebSockets is natively supported in targeted browsers.
• Socket.io P2P (which implements WebRTC connections) has a high bundle size. Also, some changes in the wrapper have been made to suit the project's needs, which tends to become infeasible in certain situations.
• There's probably some smaller specific libraries that allow more flexibility than using a single large library like Socket.io

While this migration would take time, we do need to keep in mind that following parts of Socket.io are crucial to the functioning of the app:

• File sharing rooms.
• WebRTC connections where every peer is sender and receiver at the same time.
• Support for sharing multiple types of data (i.e. ArrayBuffers and JSON data).
• WebSockets as a fallback with an upgrade to WebRTC connection when possible.

Svelte has elements like <svelte:window> that make it simple to attach and automatically remove event listeners from the window object. Right now, this code is written in the onMount of some components.

The new Web Share Target API would allow Blaze to accept file data from the native file system itself(currently on Android), thus improving the user experience of the PWA ⚡

The full implementation of this in Blaze is yet to be thought of, as joining a room adds a step to sharing files. One approach may be to make use of Anonymous rooms #46

Direct links to join a room don't work for new users. User is asked to enter a nickname and is taken to the recent rooms layout in the app.

icon-192.png and icon-512.png are not 192x192 and 512x512 size images respectively.

As Blaze was developed with the mobile-first approach, the layouts aren't responsive and can be improved especially for desktop screens.

When a user uses Blaze for the first time, the modal for joining a room opens up without giving any context on what a room is and how two different clients must connect in the same room.

I know that mobile devices probably aren't what Blaze is intended for, but just letting you know it crashed my iPhone when I tried it.

Rooms that are created may support some type of password which can prevent strangers from joining a room.
Joining a room would require a password which was set by the host of the room.

File transfer is stuck forever
when I close the safari user the room is blocked.

Blaze assumes people to have unique nicknames in a room to work correctly. Hence the backend should disallow people with same nickname accessing same room.

This will also solve the problem when the app is open in multiple windows/tabs, and the user tries to join the same room from both the instances.

The data transfer visualizer is built using SVGs on d3.js. D3 itself is a heavy library and a similar visualization can be built on HTML5 canvas without much code changes possibly using something lightweight like Canvas Elements

When some files have been transferred in a room, and then a new user joins followed by some other file transfer, the new user also gets the old list of files shared between other members in the room before.

Ideally, a new user should only be shown the files that are received by that person.

Name of the room which the user has joined must be shown.

Indicate the files that are queued for transfer. For WebSocket transfer, multiple files are sent one by one. Hence at the start, only one file is shown in the files list for the sender. This may be confusing if the sender selected multiple files, and initially sees only a single file in the list.

Current issues

While WebRTC is enabling peer to peer connections, Blaze requires a mechanism to implement multiple connections from one peer to the other peers in a room to enable many-to-many file sharing. The number of connections scales up quickly as multiple peers join the same room. This can lead to poorer performance and higher bandwidth consumption compared to the traditional server-based file sharing approach.

Possible solution

The idea of torrenting is something that closely aligns with what Blaze is trying to achieve. Files can be shared to all the peers in the room by sharing it with a few peers and those peers sharing it with other peers and so on, till all the peers have received the file. WebTorrent can make this possible as it also supports seeding on the browser. Combining this with the current WebSocket implementation(as a fallback for devices that don't support WebRTC and sharing metadata), WebTorrent is something worth experimenting for Blaze.

Drag and drop to share files can be added for desktop layouts

When the user is about to join a room, a list of previously joined rooms can be shown, along with an option to join a new room.

Add an option to remove a previously joined room from the recent rooms list.

While joining a new room, the room name must not contain characters such as #, ?, & ... which have a special meaning in a URL. When these characters are used, the app stops working as expected.

Hence the room name must be validated to prevent reserved symbols.

In the File transfer screen, the Room name shown in the top bar overlaps with the Back button making it non-clickable.

Files with unsupported file formats can be compressed to standard .zip format before they are sent. This also has advantage of reducing file sizes in some situations.

Anonymous rooms would be rooms with random names (sequence of random characters). The current method of creating rooms may involve clashes. There may be someone else already present in a room which some other user wants to use.

To solve this, anonymous rooms would act as self-destruct rooms, where a user creates an anonymous room, shares the direct join link of the form /app/t/<random-room-name> with other users. The rest of the process of sharing files would remain the same.
These anonymous rooms won't show up in the recent rooms list of the user.

I ran the README instructions but didn't know where the server or whatever was. And I'm not sure whether this is like a SHAREit competitor where I needn't install an app to use it and such, so maybe state reasons as to why this was made (e.g., just for fun or for actual use).

Transferred files can show more metadata:

• If the file was sent or received
• An icon associated with the file type
• Who sent the file
• Maybe when the file was transferred? (Eg. Sent 2 mins ago) 🤔

WebRTC works when the clients are in same network, but fails (switches to WebSockets) when they are in different networks.

The files list in the transfer page overflows vertically when a large number of files are being shared. It should be made scrollable when it overflows.

Addition of service worker with proper setup will make Blaze a PWA. Blaze was mainly built for mobile devices hence PWA addition would further improve its usability and give more native experience.

Service worker is not properly getting registered in Chrome 80 due to scope while registering. This limits the installability of the PWA.

The development server does not work correctly with the new directory structure. Only public folder is watched by Gulp. static folder should also be included.

Blaze right now allows public rooms for sharing files. But in some use cases, a room on local network would suffice for sharing files across devices in the same room.

On the Front-end:

• Show a local room in the rooms list which also shows the live peers who have joined the local room.
• The local room can be accessed in /app/t/ so that it does not conflict with other existing rooms.

On the Back-end:

• Local rooms would be created similar to how existing rooms are created except that the room name would be the client's IP address.
• To get live peers maybe having SSE (Server-side events) would be better than using WebSockets as data should only be sent from the server and there is no data to be sent from client.

Files data(name, size, etc.) which are being transferred in a room must be shared with all the clients in the room.

Stylesheets don't load correctly on Firefox after the app is built

This may fix it preactjs/preact-cli#1235

File watcher during development does not run the build process for the first time.

💡 Deploy buttons can be added to the README to allow new users to quickly deploy Blaze to their server. Following buttons can be added:

• Deploy to Heroku - as far as I know, Blaze can run on the free tier of Heroku.
• Try in PWD - since Blaze is containerized using Docker, this would quickly setup Blaze on a playground server for testing purposes.

Open to discussing if there are other similar services.

When the user is in the /app route, and then goes offline, the user must be redirected outside this route, and shown a message.

The UI for the app can be shifted completely to JavaScript which will give faster response and exclude the app code from other static pages later for SEO purposes.

Add an indicator in the app that will show whether WebSockets is being used or WebRTC for file transfer. It may not be useful for everyone but would help advanced users.

README needs to be updated to include changes in next branch