dmotz

Trying to make it effortless to build p2p apps without any setup:

https://trystero.dev

https://github.com/dmotz/trystero

Direct link to the underlying source code.

I'm the Trystero author and I'd say both libs attempt to accomplish the same goal but with very different APIs. One key difference is PeerJS uses a single centralized server by default for matchmaking, whereas Trystero offers lots of flexibility and redundancy, using various signaling connections in parallel.

You might be interested in my side project Trystero https://github.com/dmotz/trystero

It abstracts away the work of signaling and connects peers via open decentralized networks like BitTorrent, Nostr, MQTT, IPFS, etc.

I have a side project that aims to organize your ebook highlight collections with on-device semantic search. [1] Right now it only indexes your own content but I'd like to add a mode that allows you to share your collection and let others find relevant ideas via semantic search -- a discovery platform for ideas found in books. It's open source if you want a sense of how it works now. [2]

[1] https://emdash.ai/

[2] https://github.com/dmotz/emdash

This looks exciting and I'm pleased to see more and more frictionless ways of making p2p apps. I've been building a somewhat similar hobby project [1] that aims to connect peers in the browser by piggybacking on open protocols out on the net (BitTorrent, MQTT, Nostr, IPFS, etc).

This project seems to be using Hyperswarm which I've looked at for use as a peering medium but it seems like it's not supported in the browser. I'd love to implement it if that story changes since it's so easy to distribute apps on the web.

[1] https://github.com/dmotz/trystero/

This is a really nice overview of the nuances of WebRTC.

If you want to try this tech at a higher level, I maintain an experimental hobby project that attempts to abstract all the complicated parts of WebRTC into a simple API. Most importantly, it obviates the need to run your own signaling server by piggybacking on various public protocols like torrent trackers or IPFS to match peers. It's well-suited for quick projects/prototypes.

https://github.com/dmotz/trystero/

Two personal projects I'd like to get fully-baked eventually:

https://emdash.ai

My attempt to get more out of all my ebook highlights using on-device AI.

https://github.com/dmotz/trystero

My attempt at making it as easy as possible to add p2p to a web app (no server required). A "jQuery for WebRTC" of sorts.

A decade ago I built a silly JS library for folding up DOM elements like paper [1] and I eagerly anticipated using element() instead of tediously cloning nodes for every fold. Here we are ten years later and this niche CSS feature has yet to be adopted by the other browsers. Similarly, I thought I'd soon be using the CSS custom filter spec from the same era (which allows custom GLSL shaders to be applied to elements), but it also has yet to pick up traction.

[1] https://oridomi.com

Thanks for sharing, I like the name and I'll try it out. Yes, I'd like to add opt-in sharing features in the future -- seeing others' notes can be very insightful as you said.

Yes, I'd like to focus on more seamless ways to import your text and OCR is something I've considered.

Your content addressable system sounds very interesting, let me know when you have a demo.

Yes, the demo mode is a random subset of things I've highlighted and it's heavily weighted around certain topics and sparse on others, so that's why some passages don't have the strongest semantic matches.

You're right that it would be nice to see things in situ as you're reading, but it would seem that most e-reading experiences are locked down. I appreciate the feedback!

I built a tool for myself for the purpose of grokking ideas from books called Emdash [1]. Over the years I've collected reams of highlights from books and articles but until recently, rarely reviewed or absorbed them. The core of this app uses on-device ML to show related passages with similar ideas from other books you've read, and I find that going broad and exploring concepts from different angles really helps in comprehension.

I'm testing out a summarization/rephrase feature backed by LLMs that you can try in the demo. In HN fashion I'm trying to build this openly and gather feedback to see what works. I'd like to push this further in the active direction the article mentions with something like a Socratic dialogue mode where you're nudged to re-explain and examine ideas.

If anyone uses this thing/has feedback, let me know. Source is available too [2].

[1] https://emdash.ai

[2] https://github.com/dmotz/emdash

And the source of course: https://github.com/dmotz/emdash

Bit of a shameless plug but I've been thinking about this for a while and I recently built a free/open-source tool called Emdash [1] to tackle the problem. I’m a heavy ebook highlighter, but I found if I didn’t have a compelling way to review those highlights they fell out of my understanding.

My tool uses on-device semantic embedding which allows you to peruse your collection and see related passages from other books which I find really helps in comprehension when you view a related idea in the words of another author. You can also search for semantic concepts directly to see nearby ideas from various authors, which is nice for when you’re in a mood for exploring a particular space via raw concepts.

The demo mode also previews a passage rephrasing feature, which can give you a simplified or metaphorical explanation, which I’ve found really valuable in grokking dense excerpts. This part is powered by LLMs (off-device) but will be opt-in later. I’m trying to gauge interest for it, so there’s a form to sign up for a waitlist if you’d like.

Would love to hear if anyone else uses this tool and what they’d like to see in it. Source code is available too [2].

[1] https://emdash.ai

[2] https://github.com/dmotz/emdash

WebTorrent is obviously well suited for p2p file distribution, but using a minimal subset of the protocol also provides a nice hack for easily bootstrapping peer connections between web app users. Piggybacking on public mediums already designed to do peer exchange can let you rapidly prototype a WebRTC project without the hassle of running your own server anywhere.

I built a library that explores this idea: https://github.com/dmotz/trystero

And here's how it talks to WebTorrent servers to bootstrap peer connections: https://github.com/dmotz/trystero/blob/main/src/torrent.js

It also allows encrypting your peers' session descriptions to hide them from the torrent server. All of this is of course experimental and I'm very open to feedback.

I recently wrote a library to abstract away the tedious aspects of WebRTC called Trystero:

Repo: https://github.com/dmotz/trystero

Demo: https://oxism.com/trystero/

The goal is to allow adding P2P/multiplayer to your web app in a few lines and no server setup.

While there are a few good abstraction libraries out there (this one builds on simple-peer), I felt the need the set up a server for matchmaking peers was too much friction for experiments and too centralized in the context of P2P apps. Trystero abstracts away the matchmaking aspect using BitTorrent, IPFS, or Firebase behind the scenes.

Source: https://github.com/dmotz/cellf

I was thinking along the same lines and just pushed up an addition to do so. (t.disable())

That's right.

Author of OriDomi here. Really excited to see this at the top of HN.

I recently pushed out version 1.0 with some new features that make OriDomi easier to use.

It now has an internal queueing system so you can chain up effect sequences instead of dealing with callback handlers. [1] What looks like a chain of synchronous calls will now be deferred and sequenced automatically, e.g.:

folded.curl(50).collapse().setSpeed(2000).stairs(-29).foldUp().unfold();

Secondly, OriDomi elements are now fully responsive, meaning they adapt to changing dimensions caused by media queries, window resizing, etc. You can see this behavior with the demos by resizing your browser, or on the current iteration of my personal site. [2]

Finally, there are two new methods that make it easy to do custom folding behavior and content manipulation, .map() [3] and .modifyContent() [4]. The former lets you pass your own function to define folding based on input angle and panel index.

It's still relatively lightweight with zero dependencies and 7.6KB gzipped and minified. More than anything, a testament to what you can do with the modern browser API.

Looking forward to seeing what else people do with it. Check out the annotated source [5] for a look at how it works.

[1] http://oridomi.com/#queueing

[2] http://oxism.com

[3] http://oridomi.com/#custom

[4] http://oridomi.com/#content-manipulation

[5] http://oridomi.com/docs/oridomi.html

Yes. That wiggling is the "ripple" mode I added recently which adds a cascading delay. It's disabled by default when creating new OriDomi instances, but I enabled it for the demos on this page. You can also programmatically turn it on and off:

http://oridomi.com/#ripple

I owe plenty of gratitude to you for both CoffeeScript and Docco. Both made building this a pleasure.

For those interested in going beyond what the docs cover, the annotated source page is a great place to understand the inner workings.

Author here. Twist and fracture are among the more unconventional, dramatic methods that I left in for those looking for cut-up effects over folding. As you found out, you can even target the body element and the OriDomi will stretch to the window dimensions. That middle portion in the last screenshot looks like a stuck hover state probably due to the fact that you have nested OriDomi instances on the page. Thanks for trying it out.

Author here. OriDomi actually does granular feature tests and has no awareness of what particular browser you're using. While the recent versions of IE do support CSS 3D transforms to a degree, they omit support for the "preserve-3d" transform style which allows the transformations of parent elements to affect their children. Without it, the visual tricks OriDomi does don't work, so the library will disable itself if it finds the client lacks support. Whenever IE begins to support "preserve-3d", OriDomi should start working without modification.

Article here: http://blogs.adobe.com/photoshopdotcom/2013/09/introducing-a...

One thing I missed in fish was bash's sudo !! to quickly re-execute a command.

A replacement is easy enough though and is in my config here: https://github.com/dmotz/dotfiles/blob/master/functions/sudo...

Beyond a few other syntax incompatibilities, I've enjoyed using it.

Developers should take heed of the "uncanny valley" point Andrew makes. While I come across the rare example of an app that pulls off stock UI via CSS well [1], most fail somewhere along their approach and end up subtly repelling the user.

I wrote a PhoneGap app [2] and this fact was among my considerations when designing it.

The performance points are spot on with my experiences, especially avoiding any height and width manipulations. Most of the height transitions in my app are actually translations on the Y axis, preventing reflows. Rather than completely rely on the browser's native layout capabilities, it can pay off tremendously to do some of those calculations and translations manually.

[1] http://cheeaun.github.com/hackerweb

[2] http://chaincalapp.com

I think this argument, ad hominem aside, loses a bit of validity with every subsequent smartphone/tablet generation. Every advance in CPUs and JavaScript interpreters blurs the line more if we're looking at a hybrid app developed by a competent team.

As to where I'm coming from in this argument, yes, I currently develop mobile apps using web technologies. [1]

And yes, I completely agree that the majority of web view/hybrid apps I've encountered have had poor user experiences. But the field of hybrid apps is new and everyone can recall the poor user experiences of desktop web apps in their nascent era.

As with the age of MapQuest, the sample size of hybrid apps is still small and thus well-designed and well-coded apps are scarce. Aesthetics give probably the biggest impression of mobile software quality, and you can either choose to stick to stock SDK UI, or implement your own visual language. The former is safe and is the default for native development. Hybrid apps almost always fail when trying to mimic it completely and users are (at least subconsciously) repelled by the uncanny valley these apps may land in. The latter option of introducing a unique UI is exceedingly difficult to pull off, hybrid or native, but is a route of convenience for hybrid developers, but again, they usually fail to create something a user can feel comfortable with.

In short, if you're serious about your app's reception, it is more difficult to pull off the user experience using web technologies, contrary to the article's assertion. Hybrid app developers cannot rely on native UI elements and this is why they tend to be received so poorly.

So why have I chosen the hybrid approach? Mainly because I'm a futurist and I see the immense value in having an open lingua franca for app development over fractured proprietary environments. The cross platform benefits appeal to me less, and at the time of this writing, I consider iOS to be ahead of the other platforms in fidelity of rendering web content (Android 4 is catching up). I fully admit this benefit is half-baked at the moment, but I don't need any pundit predictions to know it will improve by bounds in the next few years.

JS isn't a silver bullet, but it's undeniably exploding at the moment, especially in terms of flexibility (browser, server, mobile). You could invest your time in mastering a proprietary platform's SDK, but besides only focusing on non-portable knowledge, you could also find yourself with a dying marketshare for your chosen platform. I definitely don't mean to discredit native languages by any means, I just want to convey how I came to conclude that hybrid is a safe investment in mastering. Many apps, whether simple CRUD apps, or thin front ends for REST APIs, have no specific need for native code. Even Microsoft --seen among the symbols of proprietary control -- are embracing the HTML5 stack for apps. The benefit of being able to reuse the libraries and APIs [2] when bringing an app to another platform shouldn't be underestimated, nor the potential growth of mobile-oriented common knowledge in a common language.

Is it really difficult to believe that in a few years phones will be running WebGL-powered 3D games with advanced shader effects, on par with native games? Not really, considering how rapidly we're approaching that point on the desktop. It's even easier when you consider the hybrid app bottleneck is usually DOM painting, not JS execution, and WebGL would potentially use the mobile device's GPU. This problem is almost solved already with intelligent DOM manipulation and CSS3 transforms, (or potentially other approaches [3]).

Writing a quality hybrid app at the moment is very hard. Web views have less memory available, execution is slower, and simple DOM rendering is expensive and slow unless all optimized properly. Furthermore, aesthetics are harder to pull off when working outside SDK UI sets. But hybrid apps are a relatively new field and have enormous potential. I don't it's very mature yet, but neither was the web itself for a very long time. I think having a common, open set of tools is worth defending from accusations like this one or the red herrings thrown around regarding HTML5's role in the Facebook app. This is definitely the more forward-thinking bet.

[1] http://chaincalapp.com

[2] - specifically HTML5 device APIs as well as http://phonegap.com

[3] http://famo.us

Unfortunately Firefox still lags behind WebKit for CSS 3D transforms in performance and rendering quality (antialiasing). There's a fix for the latter issue, but it involves an even greater performance hit in my experience.

I wrote another library that relies heavily on 3D transforms to do folding effects (http://oridomi.com) and it's frustrating seeing the same issues you see in Makisu in Firefox.

Mozilla's been iterating quickly, so hopefully it's just a matter of time.