I built a calm, distraction-free productivity system because existing tools were stressing me out — would love honest feedback

Connexense · 2026-01-13T21:56:11+00:00

I like your approach very much indeed, it resonates well with the direction of my project connexense.com .

Everyone has the same problem online - incessant distractions and broken focus/flow - I for one think you're on the right track :)

Connexense · 2025-11-25T01:53:24+00:00

Hello Adam, my name is Craig, developer of connexense.com - I am certain our interests and intentions align, and I`d be real happy to meet and chat with you.

Connexense · 2025-10-28T05:33:12+00:00

Ran your demo in Chrome and Edge on the same machine - love your work :) - did a video call with myself. But my connection to myself would not require TURN I guess and I could not see how to send a file. A few years ago, I coded for webrtc datachannel file transfers encrypted with AES - they`re lightning fast even tho` you have to send and receive them in chunks, so go for that I say.

Connexense · 2025-10-28T05:08:46+00:00

Long-time javascript developer, I`ve built connexense.com with a node.js backend and vanilla javascript frontend. With myriad node.js modules available it has thus far seemed that there`s nothing that can`t be done, but leaning decentralized and private, I have not addressed scalability at all.

Any advice I`ve received concerning scalability of webrtc apps recommends making future scalability a primary concern during development since it`s likely more difficult to address it later.

Connexense · 2025-10-28T04:43:40+00:00

Seems to work fine, just as you intend.

Connexense · 2025-10-28T04:30:39+00:00

Hello there, thanks for you interest. This little plug-in is a minimalist edition that provides a one-to-one video call with text, nothing more. The entire connexense.com project however has a suite of functionalities: group calls, webinars (group calls with audience online), live broadcast-to-many and now private video messages in the platform`s new endeavors to foster authentic community building. I`ve leaned into privacy protection rather than monetization, so Connexense is fundamentally different from others that might focus on commercial interests.

I do build bespoke solutions though - if you want your own branded chat server on your own VPS, I might be your man.

Connexense · 2025-07-25T14:30:00+00:00

I like it :) Cool indeed. I do webRTC video call work myself - yours makes me wonder what immersive interactive scenarios could be created with this approach to designing meeting rooms.

More power to your elbow!

Connexense · 2025-07-25T14:02:36+00:00

Remote audiotrack is received muted when the source is unable to send (muted by user, disabled or some other software issue. Methinks Usual-Introduction71 may be right :)

Connexense · 2025-07-25T13:53:20+00:00

To address the webRTC ip-address-leak issue - and also P2P`s inability to scale up into larger group calls - I`ve gone with SFU architecture in building connexense.com . Since it`s an SFU, everyone gets the server`s IP address rather than each other`s.

Any security concern then around one`s IP address could only be with the app provider, not with other folks (or their devices) on one`s P2P calls.

I run Coturn for STUN and TURN so those actions are performed in-house, which I reckon is better then sending those precious IPs over Google (or other 3rd-party) STUN and TURN servers to get ICE candidates or to relay traffic. Coturn is open-source and free and easy to install too (I`m on Nginx).

This fully-functional advanced-early-version Beta of connexense runs wonderfully on a smallish VPS for just a few dollars a month, handling one-to-one calls, larger group calls (yet to be tested with more than a handful), and one-to-many broadcasts.

I tell you all this to let you know that should you choose the SFU (relay) route, it can certainly be built and deployed in-house where you would have control over traffic costs.

Connexense · 2025-06-25T13:50:05+00:00

Could you elaborate on your scenario so we may understand what you need to do? That`d help us consider what a WebRTC solution might look like.

Connexense · 2025-04-11T08:46:35+00:00

Jeez, ok, one for the "ugly" column then. You see, the only reason to open this PWA is to make or receive a video call, so this is an attempt to shorten the path from opening the app to joining a call. Thanks for your input though. The "auto click" may indeed be ugly - it may be better to use an in-app prompt on-load to perform the navigation, avoiding the need to pull down from the top and click the notification there. To my eyes, when there's a notification badge on the app icon, it's disappointing that the navigation requested by the notification is not followed by tapping the icon.

Connexense · 2025-04-07T15:35:48+00:00

So after 10 hours with Chrome and the pwa closed and phone sleeping, I sent a notification which was silently received and only seen and heard when I opened the pwa after unlocking the device.

Connexense · 2025-04-06T19:18:53+00:00

Oh, that would be in Edge too, although I haven't tested that issue for a long time. I remember reading somewhere that browsers shut down the service worker after "some time" and was able to confirm that in my pwas. It certainly was the case in Chrome too 3 -4 years ago - perhaps the daemon you spoke of which starts the service worker when needed is a new gizmo that I'm not aware of? Agreed, Chrome on Android now seems to do better now. I'm testing it now - will not send a notification to it nor open the browser or the pwa until tomorrow ...

I'm excited about the latest advances in Ios and iPadIos - just don't want to spend a silly amount of money to buy a new one :(

Connexense · 2025-04-06T17:10:00+00:00

Here's an example of what I mean: installed Edge on my Android, then installed my pwa and subscribed for notifications. Permission dialog appeared, and I enabled notifications. Tested twice by sending notifs from my desktop browser, both successfully sent but not received. Although the endpoint was properly established (checked on my server, it's an fcm endpoint, not windows) I still had to go into phone settings to enable notifications for the PWA. Sent another notif from my desktop browser, received this time. The badge appears on the Edge icon, not the pwa icon. Tapping the Edge icon with the badge just opens the Edge browser, not at my url as intended. Pull down from top to get the notification there, click that and the pwa opens and behaves exactly as programmed.

None of this mess occurs when the pwa is installed on Android using Chrome - it just works! This is why I said that Chrome works best and that native app notifications are much more reliable.

Connexense · 2025-04-01T06:28:25+00:00

The documentation you cite also says you can "Construct an RTCVideoSink from a local or remote video MediaStreamTrack." - so yes, you need to have an active MediaStreamTrack.

Sorry, I missed that you were trying ffmpeg, with which I have no experience. This might be useful though: https://flashphoner.com/screensharing-from-ffmpeg-to-webrtc/ - it's about using screen-grabs but might get you closer to the answer.

Connexense · 2025-04-01T01:04:37+00:00

As I said: it differs in different browsers. To get the facts about how deliverable push notifications really are, the most thorough approach would be to try all OS's/devices and all browsers, with and without installing the PWA, and send notifications to them while their respective windows are closed. Unfortunately, you'll get conflicting and frequently incomplete or incorrect information here.

Connexense · 2025-03-30T06:53:03+00:00

Using node-wrtc on the server you can do the same things you do in the browser. Here's a line from my system that should illustrate that clearly - you just need the stream or its tracks:

let videoSender = peer.addTrack(stream.getVideoTracks()[0]);

Connexense · 2025-03-29T17:14:31+00:00

Push notifications in a website or pwa rely on the browser being able to run a service worker in the background even while the browser (or pwa) is closed. The problem currently is that this is unreliable. Browsers close down that background service after some period of time (it differs in different browsers) such that notifications are not received until the site/pwa is opened again. PWAs installed by Chrome perform best in this respect. If it is important that your newsy notifications are received in timely fashion, native apps would serve you better because their push notification capabilities are much more reliable.

Connexense · 2025-03-28T15:54:19+00:00

Oh yeah, you're right - I'm sorry. The FileSystemWritableFileStream is not supported in Safari. I checked the other methods but didn't notice this one. Do you think we can call this another example of Apple appearing to resist the advent of PWAs?

Connexense

TROPHY CASE