A couple of ideas for improving steemit

Improving steemit

Hi all, before I proceed with my usual posts i've had some ideas both old (had years ago back when I was a regular and while I was working at steemit).

Anyway, they can roughly be split into 3 categories: stuff that is best implemented at the lowest level as a blockchain hardfork, stuff that should be implemented in the client side (by default condenser - the software behind the web interface here on steemit.com, but there's also stuff like busy.org and third-party apps) and then there's hacks such as a bookmarklet.

Without further ado, here we go:

Chat and private messages

Chat and private messages are a feature common to many social media sites and are usually combined into the same thing - that is, you have realtime chat and all the messages are archived and can be accessed later somewhat like email.

Steemit is somewhat different from normal social media and blogging platforms in that the blockchain is a resource that must be handled carefully - inflating the size of the blockchain should not be done needlessly because every node in the network and witnesses in particular need to mirror it and there's finite amounts of disk space and bandwidth available to people.

Therefore it makes little sense to have realtime chat and messages mixed as they would be elsewhere - for one example I myself often send IMs to my wife with messages that have no requirement for longterm archiving, ranging from "hey, i'm at the shop, anything I should get for you?" to social "fluff" such as "I love you" and cute emoticons etc.

Then there's emails, which people often don't need to be informed of in realtime and can be checked later. On social media we can also have equivalents to the kind of messages people send via email.

Additionally, apart from resource usage there's also the question of privacy - currently the blockchain does not strictly speaking use encryption at all, if anything it requires everything be plaintext in order to work. Since the blockchain can be mostly treated as a longterm permanent archive, anything encrypted can be assumed to stay there forever (or at least, for a long, long time) and if it's sensitive and of a personal nature the risk is that someday currently strong encryption algorithms might be cracked.

If currently strong cryptographic signature algorithms end up being cracked there's ways we can mitigate that - we could for example sign the current blockchain with a new algorithm that is secure, and have the signing done by a trusted central party - or even several. Individual accounts can also verify their old content and sign it with a new algorithm. Then the software simply moves onto only using the new strong algorithm for transactions going forward.

Private messages are different - once cracked and the plaintext becoming available, nothing can put the genie back in the bottle if sensitive or private correspondence is leaked.

What's the solution then?

For email-style messages the easiest solution is to just publish an email address and if privacy is required also publish a GPG key, this is easy enough to do in profile metadata and then clients can display it on the profile page.
Another solution is to integrate with something like bitmessage, and have the client integrate support for the bitmessage blockchain - this pushes the privacy issues over to bitmessage (who I believe currently solve the problem of encryption being cracked in future by only storing messages for a limited time period - if you don't login for a long time to pick up your messages, they disappear - a way around this is to have a trusted party pick up your messages on your behalf).

So that's email-style messages and offline messaging sorted - what about realtime chat?

Realtime chat is something that again doesn't belong in the blockchain at all for both privacy and resource limits reasons - so the solution is to either push it to a third-party and store metadata pointing to that third party or to make it entirely client based.

I would like to propose a mixed solution - we have realtime chat implemented on the steemit.com website and use WebRTC to handle the communications layer. This way there's no extra bandwidth needed on steemit's part and realtime chat is still reasonably well integrated.

For privacy and authentication, we use the blockchain - we just need to use the existing memo key or posting key (though the memo key appears to me to be more appropriate for this usecase) to authenticate messages and as a public key for encryption. This is actually what we did on SteemPower for our private messages feature (which did use the blockchain, an approach I now consider flawed for reasons described above).

The underlying support for this functionality could be integrated into libraries like steemit-js et al so that third-party sites and apps can implement it in a standardised manner.

This kind of realtime chat could also be injected into an existing site using bookmarklets, which would require no changes at all to steemit.com (though the bookmarklet would require your private key for the memo key in order to function).

Compatibility with third-party clients that aren't web based could be an issue if WebRTC is used as the underlying transport, but this is not an insurmountable problem - in a worst case scenario all that would happen is only web clients would support the chat feature, overall not that big an issue.

Username aliases

This is an idea I was discussing on the dev discord the other day (if you're reading, hi guys). The inspiration and usecase should be obvious in my case, but there are various use cases i'll explain.

Essentially what i'm proposing is a way to simulate renaming your steemit account - I first started thinking about this due to wanting to change my own username from garethnelsonuk to gwennelsonuk, then I began to realise there's lots of ways it could be used.

It's really quite simple - we add 3 new fields to account metadata, this requires no changes at all at the blockchain level. "link_account", "redirect_to" and "authorised_linkers".

The first field, "link_account" tells the client software that when your blog is visited by another user, posts should be loaded not just from your own blockchain account but also from the linked account. The linked account should also be required to link back to you or to list you under "authorised_linkers", this prevents people from fraudulently linking other people's accounts and thus stealing credit for their work (though underlying monetisation wouldn't be affected, people's social reputations could be).

The second field, "redirect_to" tells web clients such as steemit.com or busy.org that they should redirect URLs to the named account. For example, if this was already implemented then https://steemit.com/@garethnelsonuk would redirect to https://steemit.com/@gwennelsonuk with an HTTP 302 or HTTP 301 or whatever other means is considered appropriate. The same would apply for links to individual posts.

When a client encounters a URL for a post that does not exist, it should check the link_account field(s) and if found on one of the linked accounts, load content from the linked account, assuming the linked account has authorised it in authorised_linkers.

If implemented and standardised - again, it would make sense to put the functionality into the relevant libraries, and potentially at the lower level in the steemd RPC API (in which case it'd also make sense to have an boolean extra parameter such as follow_links etc). The beauty of this whole proposal is however that it doesn't need to have support at the lower layers, it would be entirely backwards compatible. On the social level, it would make sense for it to become etiquette to make a "final post" on the old username directing people to the new one as well as updating the metadata "about" field and homepage URL to point to the new username, so that users of old clients are still able to find the new content.

Now, the obvious use case here is for people like me who want to setup a new name/identity without losing their old content, but there's another use case I thought of and undoubtedly there's others which I haven't been able to imagine - I encourage people to think about this and offer their own ideas in the comments.

The primary use case I thought of is for company blogs, or other "team" blogs. The idea is that a main company account would be setup and then use link_account to import posts from team members, who would then not need to link back but merely authorise the company account with authorised_linkers. This could even potentially be multi-tiered if implemented properly: one could imagine for example each department of a larger company having their own blog and then individual team members having their own blogs which are then imported into the department blog and then into the company's main blog.

This "import another blog's posts" concept could be expanded on in many other ways - for example, perhaps we could have a system where "imported" posts are automatically given specific tags - in order to future proof it, any  formal specs for the system should offer appropriate space in the JSON metadata for future expansion.

As a programmer I am used to languages where individual modules export particular functions, variables and data for other modules to use - the proposal here is for a similar system but with authentication essentially (and not as literal, the software module example is more of an analogy).

People have suggested similar functionality is already possible with custom feeds, but that doesn't have quite the same feature set as having an actual account with the new name - a fully featured account is of course far more appropriate at least for use cases such as my own, and I can only imagine other potential use cases.

So dear steemit users, what are your thoughts on this? I've purposefully avoided starting on any formal specs for the proposed new metadata except for a rough outline as in this post specifically because it should have more discussion.

Ultimately whatever spec is finally used should definitely have room for future expansion and should be fully backwards compatible. The same goes for the chat proposal - though I foresee that being much more complex and potentially controversial in terms of how to implement it, naturally it's simple enough to make a fully backwards compatible realtime chat system for steemit that would work with any website by using a bookmarklet to inject into the page, but it's something that would work better if there's some agreement on how to make it all work.

Therefore as regards the chat proposal, I might at some point hack together a proof of concept but I foresee it not becoming "official" (especially as there's already many chat services that are aimed at steemit users already - though they lack integration and require that users create a new account to use them). I'd be very interested to hear people's opinions on it anyway.

A bookmarklet for WebRTC chat will be guaranteed both backwards compatible and future compatible (in that it requires no changes to the blockchain and user metadata whatsoever, or even any changes to the frontend beyond the bookmarklet itself). The bookmarklet proposal though could potentially inspire other implementations which may not all be compatible with each other, and I therefore would like to proceed with caution on that front, lest we end up with multiple incompatible implementations and a fragmented userbase.

So my dear steemit users, please offer me your thoughts on both these proposals