Show HN: RelayBeam – A new way of messaging using Ports

[supritgandhi]

Hi HN! I am developing RelayBeam, to overcome the challenges faced by existing messaging platforms. I've introduced Ports based feature for contextual communication.

It organizes conversations based on context through the user-defined ports.

I've explained in detail about it with some examples at https://relaybeam.com/about

Do try and suggest any more features you'd like to use!

[vidarh]

So, a proprietary service to reinvent email aliases and folders or tags, with no hint of why I'd not just use email aliases and folders/tags.

I can't see anything that tells me why I shouldn't just have multiple emails aliases instead of trying to convince everyone to use a new service, and having to explain to everyone that this email like address isn't an email address.

[echoangle]

I agree with your point but the similarity of your comment to the Dropbox comment here on HN is funny ( https://news.ycombinator.com/item?id=9224 )

[from-nibly]

I'm pretty tired of the Dropbox line. it's not like some sort of logical fallacy to say that something that can be built with existing products isn't viable as a huge company. Dropbox smoothed a bunch of edges on a VERY thin interface: files. This is creating a very thick interface out of thin air for something that already exists and works. Also Dropbox wasn't the 4000th ding dong to try to "fix" email.

[vidarh]

They were all legitimate concerns, though. Making Dropbox "work" required overcoming all of those issues, and they did. Maybe Relaybeam can make it, but he'll need to have answers for those issues, and much more to do so.

EDIT: In fact, they have far more to overcome: Dropbox didn't have to overcome negative network effects. E.g. people will ask why they can't email instead, whereas giving people a url to get at a file did not make things worse.

[remram]

I agree with you in general but I really don't see it here. This app looks exactly like an email client.

[immibis]

When Dropbox was new, I tried it for a bit, but the only real use it got was for free website hosting. Now that I know how corporations fuck us all over and have $5/month to spend on a VPS, I would definitely share files using something self-hosted instead. I think for my use cases, any web-server works fine, for the peace of mind of not getting fucked over unpredictably in the future (which Dropbox did, when they stopped doing free website hosting)

[supritgandhi]

Hi, thanks for your comment!

But, people who are not much familiar or used to with email might find it very difficult and not so user-friendly to use email aliases and folders.

[vidarh]

That's an argument for writing an email client, not for writing a proprietary service that requires them to learn an entirely new system and convince all their contacts to move.

Put another way: Nobody but me needs to understand or change behavior to make [e-mail] work, and I don't have to configure anything - I can just make them up whenever I want (everything after the +) and set up a rule of/when I decide I want them in another folder, or want to do other things with them.

There's a case for better UI for that. There's not a case for a messaging system that isn't email, that requires my contacts to change behaviour, to do that.

[phs318u]

"Ports" seems to just be "tags" as channels/filters? The problems with all such schemes (channels or tags) when used for more than personal organisation, is discoverability by the other party. This is addressed by RelayBeam through the first party disseminating their per-port address. But this merely shifts the burden of organisation to the sending party when they have multiple relationships (and therefore multiple port addresses) with you. Now they must remember which address to use for what. This problem is multiplied as each person they interact with has their own set of port "schemes".

I admire the attempt to solve the communication organisation problem, but leaving aside any functional attempts to solve the problem (which I suspect will be readily solvable through 'message aggregator AIs'), the fact that this solution requires all users to use the same platform, makes this effectively DoA (excepting organisations that might mandate a move to such platform).

[supritgandhi]

> Now they must remember which address to use for what.

I will be introducing the address/contact book feature for each user, wherein users can save the port address with whatever name they feel comfortable. So, users just need to send a message to someone from the address book (if already added), this way users don't need to remember exact port address, rather just refer the address book.

> this solution requires all users to use the same platform

I think except email, most of the solutions will require all users to use specific platforms.

[phs318u]

> I think except email, most of the solutions will require all users to use specific platforms.

You'll find that, while not perfect, most tools like Slack, Teams, Confluence, Jira have integrations that allow various degrees of notification, activity monitoring and message transfer - either natively or via third-party solutions such as Mio [0] which creates "universal channels" that bridge Teams and Slack channels so that messages posted on one platform are visible on both and can be responded to natively.

[0] https://techcommunity.microsoft.com/t5/microsoft-teams-commu...

[from-nibly]

The problem isnt remembering the contact. Its remembering which port should be used. If I have a hospital and a church port for John and there's a church sponsored blood drive that John is leading should I send it to his church port or his hospital port?

[retropragma]

Send it to both?

[from-nibly]

Ahhhhhhhhhhhhhhhhhhhhhhhh

[irfn]

my thoughts exactly. too much focus on "Ports" while not being able to differentiate in any way

[supritgandhi]

Hi, I think using "Ports" is the unique and differentiating way of messaging here.

Do you have suggestion on any additional features? I'd be happy to discuss.

[emacsen]

I'm confused at the problem this is meant to solve.

The about page talks about fragmented communication leading to overload and complexity, but it seems this communication platform sits alongside others, not interfacing to them.

That means everyone needs to use RelayBeam to communicate?

And it also seems like the name doesn't reflect what it does, as it's not relaying message?

Also, ports aren't dynamic. You can have joe@work but if the boss messages you about a specific project, you're still stuck looking at all the messages in the @work port?

If so, I'm not sure what this will solve.

[supritgandhi]

Thanks for your comment! Fragmented communication as in, users need to jump across multiple apps or platforms for different context, simple example, people generally use platforms like Slack/Teams for internal communication and prefer email for external communication. With RelayBeam you can have single platform for both the purpose.

You can create project specific ports as well, as it can can segregate the messages as per the context. Another example: if joe is in sales & marketing department, then joe can have joe@sales and joe@marketing, which can be helpful in prioritizing the messages.

Do you have any suggestions for further improvements?

[emacsen]

I don't want to sound negative, but as a potential user, I don't see this solving any problems I have.

My communication is spread across email, Signal, Discord, Matrix, and XMPP. I have several email addresses, two Signal accounts, a Discord user, and XMPP.

The selling point on the website is that my communication is fragmented. The answer you're suggesting is "Move all your communication to my platform and it won't be fragmented." I could make the same argument about any of these. "Stop using Signal, Discord, Matrix, and XMPP and do everything by email." Worse yet, it demands that everyone else stop using these other communication mediums and I switch exclusively to this. Even if this were possible (it's not) I'd never want a single vendor controlling all my communication.

The port idea is similarly underwhelming.

What I thought you were going to offer is some kind of semantic categorization. This way I can know about all the communications that involve Project X15, but instead, I now must rely on the other party to send to the right port.

I can't even get people to update their email address for me after over a decade, so this feels like a non-starter.

At the end of the day, I don't see what this will offer me. It's yet another platform, adding to the problem of fragmented communication. It's features aren't especially compelling, and it suffers from deep vendor lock-in.

My suggestion is to find a niche for this, since I don't see it providing value as a general tool.

[dismalpedigree]

So everyone needs to use RelayBeam in order to communicate? Selling all my contacts on yet another communication tool is difficult.

[supritgandhi]

Please help me understand:

Are you asking if you have to share your contact details like phone number or email? - No you need to share any of those. You don't even need phone number or email address for creating account on RelayBeam. You just need to share relevant port address for communicating with someone.

Or are you asking about migrating all your existing conversations in other tools?

[dismalpedigree]

When using a communication tool, I assume it is to communicate with someone other than myself. It seems the other person must be using RelayBeam also. The challenge is that even if I really like RelayBeam, it adds little value if I don’t have people to communicate with. People are somewhat burned out on having a thousand different communication apps, and getting them to add one more seems like a significant effort.

[vidarh]

If I give my contacts this address, every one will 1) think it's an email address, 2) when learning it is not, ask for my email address so they don't have to sign up to something else.

[supritgandhi]

You can start using RelayBeam whenever you think ports can help you organize the conversations.

[immibis]

Only if your conversation partner also does. And if I'm selling them on a new app, why not SimpleX, which is decentralized (I think?), has actual privacy, and even easier to install than something like Whatsapp?

[marcus_holmes]

I don't see how this solves any of the problems listed:

> With multiple channels and threads, users struggle to maintain context, often jumping between discussions.

> Channel clutter and disorganized conversations making it hard to follow important discussions.

> Limited external communication capabilities compared to internal use. (Applies to other messaging platforms)

> The flood of notifications from various channels can overwhelm users, causing distractions and stress.

> Time-consuming management of overflowing inboxes.

> Susceptibility to spam and security risks like phishing attacks.

Literally none of these problems seem to be solved by adding what appears to be the same thing as inbox filters. And the page doesn't explain how they think it does.

The big one being spam - how does RelayBeam stop unwanted commercial messaging?

[supritgandhi]

Hi, I'll try to explain it as follows:

> People switch between multiple apps and channel for different purpose, ports can help to distinguish messages based on context and purpose.

> Having different types of discussion in handful of channels makes it difficult to track important messages, with multiple ports you can just focus on the important ones and ignore others.

> Users generally use apps like Slack/MS Teams for internal communication and prefer email for external communication. RelayBeam can be used for both the purposes easily.

> Again using ports, this can simplify the information management, because users can search for information in the relevant port.

> Generally email addresses are available on many sales directories websites. And your work related emails can be searched through such directories. Using different ports, you can just display certain ports publicly, and even if you don't make any of your ports publicly available, then I don't think it would be easily discovered, which should solve the spam problem to some extent.

Let me know if you'd like to know more on any of the above.

[marcus_holmes]

Thanks for the reply :)

I use the "[e-mail]" trick to filter my email. That feels like the same approach as you're describing for ports. Is it? How are ports better?

The Slack vs email thing is not because email is lacking, in particular, but that chat feels more immediate while email feels more professional and permanent. How are you going to make RelayBeam feel both professional/permanent and immediate?

I still don't see how it solves spam, though. My email address is sold, by services that I legitimately signed up for, to shitty marketing companies who then spam me. How are you going to stop the same thing happening for ports?

But hey, good luck with it. Hope it works :)

[supritgandhi]

Hi,

Regarding, [e-mail] - Yes, that is one of the feature I am trying to improve, given many people who are not that comfortable with email might find it difficult to configure it.

And for spam, a considerable amount of spam messages are automated using different tools or platforms. Sending automated messages won't be possible through RelayBeam, because marketing companies won't have any tools or APIs to do so.

This should solve the spam issue to a large extent.

Thanks for your comment!

Feel free to ask if you have any questions!

[vidarh]

> might find it difficult to configure it.

There is nothing to configure. If you want to filter it into folders, then, sure. That is an idea for a feature for e-mail clients, or an e-mail provider (*), not for a separate communications services.

> Sending automated messages won't be possible through RelayBeam, because marketing companies won't have any tools or APIs to do so.

That makes it a total non-starter, because a lot of the messages I use filters to organise are automated messages I want and/or need to receive. So now I then still need to hold onto my e-mail because the proprietary platform you're trying to push is trying to tell me how and who can and can't message me.

To me, that you can control this means it's not something I'll consider a viable option.

(*) I used to run an e-mail service where username+[folder]@domain would automatically send the message straight to the named folder, but this is also easily achieved by providing a filter.

[saintfire]

I solve this problem the exact same way using emails.

e.g. [e-mail], [e-mail], [e-mail]

RelayBeam essentially flipped the email address to make the domain into the username. Except, it seems less robust.

In an example it says John is a doctor and uses the john@hospital and john@home.

Incidentally John is a popular name. I don't really trust JohnK1984@hospital over the email equivalent [e-mail]

The hospital can also have an info@..., support@..., noreply@... How does a business do that with relaybeam? It's going to be hard to have work related comms on a system that is managed by the employee.

[supritgandhi]

Hi, thanks for your comment!

You have exactly pointed out why I am building RelayBeam. You mentioned that you create multiple emails for different purpose, with RelayBeam you don't need to create multiple emails.

Now for naming, I can easily create a verification service, where certain port addresses can get verified, and if the port address gets verified, I can just share 'Verified' badge next to port address, and this badge will have all the details like which organization is this person related and so on.

And once you have the port address, you can save it to your address book with any name you feel comfortable. (Will be developing this address book feature)

Do let me know what other ideas do you have to solve this problem? Let's chat!

[vidarh]

I don't need to create multiple emails. I have infinite e-mails:

If you e-mail vidar+[any string]@hokstad.com it works, and I can filter that however I want.

That has worked with multiple providers for 25+ years (both Gmail and Fastmail supports this; my own e-mail service used to support it back in the day, and if there was a corresponding folder it'd deliver straight to that folder), and doesn't require me to explain a new service to people.

[kamma4434]

Ah like gmail where you can have [e-mail] and [e-mail]? One usually creates a second account if that’s not supported.

[zem]

did anyone else think this was going to be an erlang-based multi-language rpc system?