The neural band always looked more interesting than the glasses tbh.
I've been moving more and more away from terminal and IDEs, and I've been exploring how I could move to a flip phone / table + compact keyboard as most of my development time is now possible to be done via just using TTS.
I'd be interested in exploring if something like this could remove the need for a mouse or touching the screen as well.
Some alternatives that are not bound to the meta glasses: Mudra Link (USD 299), Mudra Band for Apple Watch (USD 350), MindRove Armband (USD 800, wow), SiFi Labs SiFi Band (no price), OYMotion gForce Pro+ (USD 1250, ok this side project is starting to look expensive)
Yep, and IMHO that's why eye tracking even though is amazing when it does work is still very limited. We do a lot of small things without even realizing and stopping to do movements we are not aware of is very very hard.
I think the inertia of familiar input devices is way too high for something like that to gain any sort of traction. For better or for worse, the mainstream user is probably not leaving his QWERTY keyboard and his touchscreen, even in use cases where those are highly suboptimal.
IMHO inertia isn't the biggest factor, training requirement is.
I switched recently from mouse to touchpad and ... next day my great ergonomic mouse was basically in a drawer. Meanwhile when I tried to use Tap Strap the first step was to learn combinations with basically no gradient of feedback, it was either success or failure.
Inertia isn't such a big problem if the investment is small but if you have to learn an entirely new way then it's a huge risk.
Keyboards are wildly suboptimal. Inertia is only an issue when you replace suboptimal with only slightly better suboptimal. The transition period from blackberry (keyboard-based phones) to iphones did not take long at all (relatively speaking of course).
suboptimal for which tasks and what's better then?
I spend a LOT of time with different interfaces
(eye tracking, 6DoF controllers, pens, touchpad in keyboard, ergonomic mouse, etc) and... basically if there is 1 thing I'm confident about is that input methods are very task dependent. If you want to input text, especially hard to pronounce keywords and symbols, keyboard is great, if you want to move a pointer at arbitrary position in 3D keyboard sucks. It also depends on the context, behind a desk vs on the move is totally different.
I'm trying to work out how the OP's system would look like and I was wondering the same.
---
There are at least three parts that you'd need to solve:
1. AFAIK there is no single globally canonical Firehose. Different relays aggregate different sets of PDSes, and some might decide not to include your PDS if they don't like your content. The Firehose also isn't really the authority here. It transports signed updates from account repositories.
2. In theory you could make up a new kind of DNS record instead of NS, called PDS, PLC, or something. You'd ask your TLD registry to publish something like `PLC <did>` instead of the NS records for your DNS server.
The value should probably be the account DID (that's the PLC mentioned above), rather than the address of its PDS. The account DID is the stable identity that signs the repository updates. The PDS is just the server currently hosting that account's repository, and its address can change.
3. You then have a bootstrap problem. To get from an account DID to its PDS, you resolve the DID document and look for its `#atproto_pds` service entry. But `did:web` resolution uses HTTPS and therefore DNS. `did:plc` uses the PLC directory, but reaching that directory and then reaching the PDS URL also normally requires DNS.
So the DNS replacement would depend on the old DNS system to discover the server containing its DNS records.
---
Then, as an example, Google's DNS resolver at 8.8.8.8 would subscribe to one or more Firehoses, index DNS records from account repositories, and verify that their updates were signed by the DID named in the registry record.
Querying would then be something like: you look at the top-level record for the domain, see that there is no NS entry, find the PDS or DID entry, and look in your local Firehose-derived database for DNS entries signed by that account.
If the records aren't there, you might resolve the DID, find the current PDS, and fetch the repository directly. But that brings you back to the bootstrap problem.
Maybe the registry record would need to include both the DID and some kind of glue-like PDS address. Or perhaps the new system would need an independent way of resolving DIDs and locating PDSes without using DNS. I'm not sure what that would look like, especially once you include PDS migration and key rotation, but I think this is an additional part the proposal would need to solve.
Fragments are useless outside a browser and lead to problems. A lot of command line and library HTTP agents ignore the fragment part of an URL, so you often might encounter everything after # stripped. Thus forcing you to invent yet another HTTP client/agent/URL library in a ton of languages.
Yes, this is just how fragments work; they're supposed to be stripped before sending the request to the server. This is exactly why, in the context of the thread, the fragment is the correct place to put the TSON hash parameter.
It is fine to have the fragment stripped before sending it to the server. What I meant was that client-side parsing of TSON in many languages will be hindered by the client-side libraries stripping the fragment far too early. Because you will need that fragment part for validation, but if your parse_url-function dismisses the fragment because nobody ever needs it...
I did a cursory look through a number of major languages and libraries*, and as far as I can tell, they all retain and provide access to the fragment by default. Maybe some of them didn't in the past, or the APIs that I found superseded older ones that didn't, but at least in the present day, this doesn't seem to be an issue.
* = Including urllib.parse (Python), url_parse (PHP), java.net.URI (Java), System.Uri (.NET), net/url.URL (Go), curl_url_get (libcurl), URL (JavaScript, which calls it the "hash"), url::Url (Rust), Boost.URL (C++)
been playing around with similar stuff as well just for fun but I'm not happy with any solution so far :( -- if there is anything you can share I'd love to take a peek :)
Any suggestions for UK alternatives for cutting and bending the steel sheets needed for the chassis to the suggested US company in the video? I’ve reached out to a couple for quotes a couple of days back but haven’t heard back yet.
The second is the most similar to the company in the video, but the first is a much more established company. If none of these can do what you need, I suggest looking around the large manufacturing cities, so sheffield/derby/birmingham where there are still lots of small bespoke workshops that service large companies like forgemaster, rolls royce and JLR etc....
I’m not really sure how much of a problem this truly is and I would have appreciated if the author made a little bit more effort and backed at least some of their claims with some citations as I’d genuinely interested in leaning more. The way this is presented feels very hand wavy and over sensationalized.
> Your fight or flight is stuck on ON mode. Total sympathetic nervous system dominance.
> You can’t just snap out of it, you blew your dopaminergic load and are literally burning neurons.
> No parallel processing, your brain cant’t handle it.
> Productivity plummets, meaning evaporates, creativity disappears…
> Direct correlation between IQ and noise tolerance.
> Our GABA system can’t keep up with modern demands for inhibition.
The overall style is also very much to my personal liking.
Unabomber picture with an edited quote was my first issue.
I've been moving more and more away from terminal and IDEs, and I've been exploring how I could move to a flip phone / table + compact keyboard as most of my development time is now possible to be done via just using TTS.
I'd be interested in exploring if something like this could remove the need for a mouse or touching the screen as well.
Some alternatives that are not bound to the meta glasses: Mudra Link (USD 299), Mudra Band for Apple Watch (USD 350), MindRove Armband (USD 800, wow), SiFi Labs SiFi Band (no price), OYMotion gForce Pro+ (USD 1250, ok this side project is starting to look expensive)
reply