Projects on my wish list for the next year

SSB

• A flexible query engine (sql? datalog?) with a nice API for producing tables and indexes from the logs.
• Improved filesharing. You could post a file of any size, and it'd stay available for everybody, until it was no longer relevant and then it would clean out of the system. Only necessary files would optimistically download, and the rest would download when you ask for them. Bonus points: strong media-streaming. (Paging @mafintosh & hyperdrive.)
• Multi-device user identities.
• A distributed whois protocol, which allows you to get profile-data for a given ID, and which includes Web-of-Trust information ("this person is trustworthy because of verifications by Bob and Alice").
• A distributed search protocol, which allows you to run queries on peers' computers if your local computer's results weren't good enough, and merge the resultsets. (This would include user-search, which is the reverse complement of whois.)
• A secure-proxy protocol over pubs, so that you could establish direct connections with other users. Chat, direct mail, secret file- and drive-sharing, API calls (such as the whois and search APIs).
• External-identity confirmation protocols (ala Keybase.io) which add DNS, twitter, and github account confirmations to profiles.

Patchwork

• A much better social directory. More detailed user profiles, user lists, etc. No trouble finding people, even if they're outside your immediate network.
• Friend requests. You find the user in a directory, you send a friend request, they accept, you are now friends.
• A more useful, obvious integration of bots (pubs) which doesn't require invites.
• Secret and public groups.
• Multiple windows, and (maybe) tabs.
• Support for multiple accounts on your machine, and for switching between them.
• Editable posts
• Better feedback about network connectivity (am I syncing with everyone?)
• Better control over who I connect to (sneakernet mode).
• Plugins for userland updates to Patchwork. This would including adding new message types (photo albums, events, polls, etc) and toolsets. (Paging @jfawcett.)
• Website publishing on SSB. Sites open in their own electron window and get permissioned access to the SSB/Patchwork APIs. (Possibly via git bundle?)
• Tools for publishing security advisories about files published in SSB, including plugins and websites.
• A big beautiful docs and downloads site.

Multiple windows, and (maybe) tabs.

Where is the dividing line between this and a browser?

Website publishing on SSB. Sites open in their own electron window and get permissioned access to the SSB/Patchwork APIs. (Possibly via git bundle?)

This is a browser :)
So basically its a succutlebut enable browser. It not the first domain spefic browser. Maybe there is a way to generalize this. What do you think about have a browser that supported node.js plugins?

I suspect ipfs folks would be interested in collaborating on some of those tasks

I do think a collaboration's in our future. Right now I'm talking to @mafintosh about Hyperdrive. Hyperdrive and IPFS both have strong tech and talent behind them, but IPFS has traction, while Hyperdrive has a smaller surface area and less functional overlap with SSB, which makes it a nicer fit. I also know @mafintosh a bit more, personally, and trust his engineering. There's nothing forcing one or the other, though, and if there are IPFS experts on hand, ping me so we can talk about it.

The matrix.org folks would be interested (and are working on) this.

I'd be interested to talk to them. What's a good way to get in touch?

Personally I'd be happy if patchwork ran a local server that I could use with my normal browser.

UI in the browser?

@du5t heard, valued

I would also be willing to wager you that browsers as a nexus of web activity and content won't last another 10 years.

this is intersting. I think there might be a shift from browsers to ephemeral VM's. A browser can be thought of a VM. But most ppl still think of it as html rendering platform + JS.

previously we did have the client in the browser, and we probably will make that possible again, but to fully run browser we'd have to use js crypto, which is too slow. we have talked about a sort of lite client that ran in the browser, "preview mode"

my wishlist additions:

• direct connections with peers over WebRTC using pubs as signal introducers
• a "vocabulary management" protocol like RDF, where we can define, extend, and share domain models (schemas) for the content of messages
• a "membership management" protocol for group identities

@null_radix if you haven't already, you'll probably enjoy Alan Kay's "Normal Considered Harmful" talk

browser suck, but they are basically the right idea: download untrusted applications over the internet and run them in an sandbox. Note that both ends of the cloud use this model. You consider your code uploaded to a VM in ec2 to be trusted, but amazon don't and they protect their physical hardware from you by running your code in a simulation of a real computer.

Of course, this was never what browsers where conciously designed for, so we ended up with a whole bunch of other cruft, but really, the browser is a hypervisor.

download untrusted applications over the internet and run them in an sandbox ― @dominic

four years later and we've learned that you probably can't do this safely. hypervisors are definitely useful, but they can't protect you from malicious code.