Roamit Super Suggestion

[mrandreastoth]

I can see the concept of Roamit taken further and made into a really powerful open-source and platform-independent content-transfer system by implementing the following changes. Think Send Anywhere but on steroids.

A registered user can send any of the currently supported Roamit content either locally in a similar way to how Send Anywhere does it with its six-digit code transfer mechanism; however, if transferring to the same user, then no code is needed replicating the current Roamit behaviour.

If, however, any of the content is sent remotely, then, as per Send Anywhere, the content is uploaded to the cloud. However, in this case, instead of storing the content on whatever service that Send Anywhere uses, the content is instead stored on the cloud-storage-provider of the user's choice (to start with only Dropbox would be supported). This is an advantage to the user since they don't have to pay extra for storage. This also allows for any service fees Raomit may charge users for using the optional cloud-based portion of the service to be kept to a minimum making it more competitive in the marketplace.

The Roamit cloud-based service would allowI can see the concept of Roamit taken further and made into a really powerful open-source and platform-independent content-transfer system by implementing the following changes. Think Send Anywhere but on steroids.

A registered user can send any of the currently supported Roamit content either locally in a similar way to how Send Anywhere does it with its six-digit code transfer mechanism; however, if transferring to the same user, then no code is needed replicating the current Roamit behaviour.

If, however, any of the content is sent remotely, then, as per Send Anywhere, the content is uploaded to the cloud. However, in this case, instead of storing the content on whatever service that Send Anywhere uses, the content is instead stored on the cloud-storage-provider of the user's choice (to start with only Dropbox would be supported). This is an advantage to the user since they don't have to pay extra for storage. This also allows for any service fees Raomit may charge users for using the optional cloud-based portion of the service to be kept to a minimum making it more competitive in the marketplace.

The Roamit cloud-based service would allow users to optionally register with the service as well as registering access tokens for supported cloud-based storage providers.

When the user shares content through Roamit, they can choose to auto-expire the link and, optionally, to auto-delete the content (by default it would auto-delete).

(I suggest that, when the user assigns a cloud-storage-provider to Roamit, Roamit then asks the user to provide a path where Roamit stores content.)

Roamit then manages the content and the links it creates on the cloud-storage-provider by expiring and optionally deleting shares and deleting or archiving files (as defined by the user). (Roamit may even move content around from an "active" folder to an "archive" folder if that's what the user has chosen as an option.)

The only issue I see right now is that Roamit is currently using Microsoft's Rome API which appears to be tied to Microsoft technologies and supported platforms. This technology would possibly have to be replaced/replicated. It may or may not help that Rome is open-source since it may still wrap Microsoft technologies that would need to be replaced.

Note that the reasons why the dependency on the Rome API may be bad is not only that Microsoft has a habit of retiring services but only that it would require everyone to create not only a Roamit account, a cloud-storage-provider account, but also a Microsoft account. And, even then, that would not allow the system to be cross-platform, i.e., one wouldn't be able to send/receive content from Linux, macOS, iOS, Android, Windows, etc., etc. to allow Roamit to be a truly powerful content-transfer service that could become a de-facto standard.

A few notes about how Roamit would operate...

Roamit content transferred as links do not require the receiver to have Roamit installed.

Roamit links are direct links to the content on the storage provider. (A better alternative would be for the links to be Roamit server-based and redirected to the storage provider content. Using such an intermediate linking mechanism would prove advantageous for future expansions of the Roamit system, for example, to implement restrictions such as user-accesses-control.)

Clipboard content transferred as links are stored as files containing the clipboard data to be transferred using a published format that Roamit defines including a file extension identifying the file content as Roamit clipboard data. Clipboard data transferred this way may be downloaded as a link but may or may not be useful to the recipient unless they have an app that can read Roamit clipboard files.

In addition to supporting ad-hoc transfers, Roamit would also support push notifications for receiving data pushed to them.

Content can be pushed to multiple recipients.

To support local ad-hoc transfers, like Send Anywhere does, the receiver would need to run Roamit and would initiate a transfer by the user generating a six digit transfer code that the sender then has to enter before the content is even able to be transferred. That code is valid for one transfer session which may contain multiple items (files and/or the clipboard content if selected). The receiver then chooses what of the content to accept (for example, they may choose to accept the files but not the clipboard content).

The receiver can also register user names and passwords for individual users and can assign an optional transfer profile per device for each user. These profiles let the receiver override the default transfer behaviour (which the user also defines). Doing so allows for accepting transfers without the need of exchanging a six-digit code per transfer. This allows Roamit to not only act as Send Anywhere but also as classic Roamit currently does.

If the sender is a registered user with the receiver, the sender can then push content to one or more receivers at a time. sender can push the clipboard onto the receiver(s) for the receiver(s)' clipboard to auto-update, or push a link onto the receiver(s) for the link to auto-open, or push files onto the receiver(s) for the files to auto-save. However, how the content is actually handled depends on the receiver(s)' transfer profile(s). The sender can only suggest how the content is to be handled.

For clipboard transfers, receivers can be set to auto-update, ignore, or notify; where notify lets the user view information about the pending transfer with the option to dismiss or accept the transfer and view the content or directly update the clipboard.

For links, receivers can be set to auto-open, ignore, or to notify; where notify allows the user to view information pertaining to the transfer and can then dismiss or accept the transfer and view the URL or directly open it.

For files, receivers can be set to auto-save to a predefined path, ignore, or to notify, where notify then allows the user to view information pertaining to the transfer and then to dismiss or accept the transfer and save the data.

In local mode, Roamit would need to support connecting over LANs (wired and wireless), ad-hoc WiFi, and Bluetooth. In local mode no Internet access is required since the transfers are peer-to-peer without any server involvement (users and their transfer profiles are stored and defined on each device and not in the cloud). users to optionally register with the service as well as registering access tokens for supported cloud-based storage providers.

When the user shares content through Roamit, they can choose to auto-expire the link and, optionally, to auto-delete the content (by default it would auto-delete).

(I suggest that, when the user assigns a cloud-storage-provider to Roamit, Roamit then asks the user to provide a path where Roamit stores content.)

Roamit then manages the content and the links it creates on the cloud-storage-provider by expiring and optionally deleting shares and deleting or archiving files (as defined by the user). (Roamit may even move content around from an "active" folder to an "archive" folder if that's what the user has chosen as an option.)

The only issue I see right now is that Roamit is currently using Microsoft's Rome API which appears to be tied to Microsoft technologies and supported platforms. This technology would possibly have to be replaced/replicated. It may or may not help that Rome is open-source since it may still wrap Microsoft technologies that would need to be replaced.

Note that the reasons why the dependency on the Rome API may be bad is not only that Microsoft has a habit of retiring services but only that it would require everyone to create not only a Roamit account, a cloud storage provider account, but also a Microsoft account. And, even then, that would not allow the system to be cross-platform, i.e., one wouldn't be able to send/receive content from Linux, macOS, iOS, Android, Windows, etc., etc. to allow Roamit to be a truly powerful content-transfer service that could become a de-facto standard.

A few notes about how Roamit would operate...

Roamit content transferred as links do not require the receiver to have Roamit installed.

Roamit links are direct links to the content on the storage provider. (A better alternative would be for the links to be Roamit server-based and redirected to the storage provider content. Using such an intermediate linking mechanism would prove advantageous for future expansions of the Roamit system, for example, to implement restrictions such as user-accesses-control.)

Clipboard content transferred as links are stored as files containing the clipboard data to be transferred using a published format that Roamit defines including a file extension identifying the file content as Roamit clipboard data. Clipboard data transferred this way may be downloaded as a link but may or may not be useful to the recipient unless they have an app that can read Roamit clipboard files.

In addition to supporting ad-hoc transfers, Roamit would also support push notifications for receiving data pushed to them.

Content can be pushed to multiple recipients.

To support local ad-hoc transfers, like Send Anywhere does, the receiver would need to run Roamit and would initiate a transfer by the user generating a six digit transfer code that the sender then has to enter before the content is even able to be transferred. That code is valid for one transfer session which may contain multiple items (files and/or the clipboard content if selected). The receiver then chooses what of the content to accept (for example, they may choose to accept the files but not the clipboard content).

The receiver can also register user names and passwords for individual users and can assign an optional transfer profile per device for each user. These profiles let the receiver override the default transfer behaviour (which the user also defines). Doing so allows for accepting transfers without the need of exchanging a six-digit code per transfer. This allows Roamit to not only act as Send Anywhere but also as classic Roamit currently does.

If the sender is a registered user with the receiver, the sender can then push content to one or more receivers at a time. sender can push the clipboard onto the receiver(s) for the receiver(s)' clipboard to auto-update, or push a link onto the receiver(s) for the link to auto-open, or push files onto the receiver(s) for the files to auto-save. However, how the content is actually handled depends on the receiver(s)' transfer profile(s). The sender can only suggest how the content is to be handled.

For clipboard transfers, receivers can be set to auto-update, ignore, or notify; where notify lets the user view information about the pending transfer with the option to dismiss or accept the transfer and view the content or directly update the clipboard.

For links, receivers can be set to auto-open, ignore, or to notify; where notify allows the user to view information pertaining to the transfer and can then dismiss or accept the transfer and view the URL or directly open it.

For files, receivers can be set to auto-save to a predefined path, ignore, or to notify, where notify then allows the user to view information pertaining to the transfer and then to dismiss or accept the transfer and save the data.

In local mode, Roamit would need to support connecting over LANs (wired and wireless), ad-hoc WiFi, and Bluetooth. In local mode no Internet access is required since the transfers are peer-to-peer without any server involvement (users and their transfer profiles are stored and defined on each device and not in the cloud).