Dat: Lessons
Now that Beaker 1.0 is in beta, I have been sinking time into it. I’m very impressed - and I’ve crossed out the issues below that no longer apply.
I was very unsure about the direction that Beaker was headed last year - there was a lot of work on ‘social’ features that didn’t appeal. But they also put a lot of work into improving the protocol. Although I felt disheartened that multiwriter support was laid aside. This truly seemed the most crucial missing piece.
However, now that I’m using it again, I’m very happy with the new additions:
- The system drive. All bookmarks, contacts and hosted drives are saved to a master hyperdrive. (The filesystem unit that can be shared on the network.) This is sweet because I can access these browser settings like any other hyperdrive.
- Drive forks. There was already a mechanism before for forking a drive. (Making your own copy to edit.) But now there is a way to connect the fork back to the original drive. You seed the fork from Beaker and it adds it to the original drive’s fork list. You can also merge changes from that list.
- Mounts. These are like symlinks, where you can embed a drive within a drive. It’s just a nice touch. Though I’m uncertain whether these are automatically seeded.
- The built-in editor, explorer and terminal. These are VERY nice additions and really show that this is designed to help everyday users get comfortable peeking behind the sheet. People are always complaining about losing ‘View Source’ in the browser. This innovates on ‘View Source’.
- Profiles. This is an interesting one. Basically you have a drive that acts like a user directory on Windows or OSX. When you use the microblogging app, you post files to that profile. And you ‘follow’ by adding those profiles to your address book. It’s interesting that if, say, someone made a YouTube clone that used the address book, you would be automatically subscribed to your whole address book on that new site. It turns the whole Beaker ‘Web’ into a cohesive community. I guess we’ll see how that works out.
There are still some performance needs - each page has a slight delay while it loads. But this is a tremendous piece of software. After a solid week of slamming this thing day in and out, I feel no frustration. Just pure adoration.
01 July 2019
Okay, dove in headlong with Duxtape: I’m beginning to see what Dat and Beaker really are like—in a practical sense. I’ve also spent so much time debugging that I need to keep more of a diary of what this transition is like.
Beaker is experimental—and I’m tempted to quit it sometimes, because something doesn’t work. However, I’m learning that quite a lot DOES work—and I am just bumping my head against edge problems. It is one of my tultywits, though! I need to push for it—there isn’t anything nearly as promising right now.
Problems I’ve run into:
Sites don’t stay seeded when you close the browser. (Major.) (This is
now the case in Beaker 1.0.) This is
a problem with Duxtape—people will create a tape and then close the browser.
I sometimes find myself doing this! Since Beaker is kind of like a browser AND a
server, it makes sense to keep Dat running as a
daemon. And, like the link
describes, to keep a system tray icon running.
There’s also a related issue: ‘increase default seeding duration’ that seems appropriate.
(Along similar lines, I wish datPeers could continue running on sites that you’re seeding. This is tricky—but it would be REALLY cool to have a kind of service worker that could access datPeers for an archive. This way a Duxtape could continue to advertise itself while it’s being seeded. I am NOT complaining, though! DatPeers is sick—I love having it.)
Large files uploaded through writeFile crash Beaker. (Seems major.)
(No longer seems to be an issue with Beaker 1.0.)
I’ve filed a bug with
some clues as to where the problem is. You can definitely upload files through
Beaker’s library pages—the problem here is that my Duxtape editor doesn’t
allow large music files. It would be great to figure this out. Some platforms
crash even on ~8MB files.
The globalFetch API doesn’t work just like the Fetch API. (Minor.)
(This API is gone in Beaker 1.0.)
I have now worked around this, but it was frustrating at the time. I also
filed a bug,
specifically related to redirects. This is pretty easy to fix, but illustrates
that experimental APIs aren’t hammered out yet (obv).
Address bar problems on Linux. (Minor) (FIXED.) If I install basic Ubuntu, these go away. So
this has something to do with my dwm setup. I’ve actually
identified
the problem! The isVisible method is always false—for some reason, the
window manager is not reporting this correctly. As a result, I cannot ever type
into the address bar. This seems like an Electron bug, but who knows.
Things I’m discovering:
Dat really isn’t a replacement for HTTP. For example, I think Webmentions are better done on HTTP than on Dat. And, really, Webmentions are just the dead simplest form of a REST API—which, I’m not sure how such a thing would look on Dat.
There also isn’t a “server-side” with Dat—and this is important when it comes to something like permissions. In a way, I wonder if Github is showing us the avenue: the code is all distributed, but the centralized workspace assists negotiating collaboration—although it would be nice if more of it was distributed: the logins, the issues, the messaging. I could see Dat and HTTP having the same relationship in Beaker as Git and HTTP do on Github.
(Still dreaming more dreams for this page…)
