Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Email service DAC for the use by other DACs ?  (Read 304 times)

Offline gamey

  • Hero Member
  • *****
  • Posts: 2252
    • View Profile
Email service DAC for the use by other DACs ?
« on: April 29, 2014, 02:18:28 PM »

 Are there any plans for an email DAC?  Basically a DAC that sells email service to other DACs.  From what little experience I've had dealing with email gateways it is a huge hassle and prone to breaking.

The problem with DAC is that they have to have an interface that relies on one of 3 things currently.

1) Web-site frontend - Extremely centralized.
2) Client app - Requires trust in app.  Somewhat centralized due to distribution channels, yet this will be defacto interface.
3) Blockchain transactions - This is the best since any wallet should allow interaction with the service.  Quite a few services can get by with this level of functionality, but it is still limited.

However there is a possible 4th which is email.  Everyone uses email.  EVERYONE.  Instructions can be sent in email.

If there is an active developer behind it, then I would say it is not that centralized.  The problem is it would need to be agile in changing the email gateways.  This requires an active dev for the life of the DAC.

Lets face it, when you use a website you rely on email for most websites of importance, or at least those that involve any form of equity.  The only other way for a DAC to give a user feedback is one of the above 3, of which only #2 is decentralized and more functional than email.

So why not just rely on the decentralized downloaded client ?  The problem is there are a lot of situations where you do not want to rely on the user to load the executable and view results.  You need a technology that pushes results TO the user.  Thats one reason why email is important.  Everyone from individuals to corporations to all manner of websites rely on email. 

Another reason is it allows you to tie things into email addresses etc.  You can promote to email addresses.  Yes, that is somewhat centralized but end users do not want to be backing up private keys and dealing with all the headaches involved.  Email is a bridge to people who might otherwise be scared (and rightfully so) of downloading a client.  You can make a website be the portal to a DAC if the DAC has email access.  Create the account with email authentication in the DAC, so if website goes away they're still inside the DAC.

This DAC simply allows other DACs to utilize this other channel of communication which is the most basic functionality of the internet.

I am not sure how to structure the functionality so it is actually "decentralized".  Dealing with possibly spammers, etc.  It is a serious job in itself to keep the DAC up and running.

This could also be done with twitter etc.

The idea here is to enable other innovative DACs.

I suppose you could have like an API based DAC.  Then individual operators could provide the email service through this API and the decentralized aspect would be the routing of the email.  With each operator charging whatever the market will bear.

Has this been hashed over yet ?

Thoughts ?
« Last Edit: April 29, 2014, 10:36:18 PM by gamey »
I speak for myself and only myself.

Offline bitcoinba

  • Full Member
  • ***
  • Posts: 192
    • View Profile
Re: Email service DAC for the use by other DACs ?
« Reply #1 on: April 29, 2014, 02:30:48 PM »

Offline gamey

  • Hero Member
  • *****
  • Posts: 2252
    • View Profile
Re: Email service DAC for the use by other DACs ?
« Reply #2 on: April 29, 2014, 06:38:06 PM »
I like the idea of keyhotee, but the reality is that it sets up another huge barrier to adoption for Bitshares/I3 derived DACs if one relies on it at this stage.   It just isn't there yet.

Also, email is a "push notification" if you will.  Lots of digitally connected people (and some not so digitally connected)  use emails on their phones.

The idea seems bland as hell.  It is only a service DAC to enable other DACs to interface with the world in a quasi-decentralized manner that is already the most widely adopted private message mechanism.

I could literally write pages and pages of possible use cases.  It seems like an obvious idea to me and I'm wondering why I haven't seen it considered ?  Maybe because of keyhotee ? 

The reason this popped in my head is I suggested to Hackfisher that he put in a way to "make it rain" lotto tickets.  (for those without strong english, it means to throw money in the air so it rains down)  The problem is you really can't do this because the ticket redemption code can be intercepted unless sent via a private message.  However there isn't any private message inside DAC until someone downloads a client and checks it regularly.  Maybe that is a good thing, it is hard to judge.... 

I just know email is used for marketing and account information/updates all the time.
« Last Edit: April 30, 2014, 04:40:04 AM by gamey »
I speak for myself and only myself.

Offline jwiz168

  • Sr. Member
  • ****
  • Posts: 409
    • View Profile
Re: Email service DAC for the use by other DACs ?
« Reply #3 on: April 30, 2014, 04:15:23 AM »
wait for Keyhotee 3.0  ;) . The fact is Keyhotee has the working framework of a messaging system. So what I3 would do is to enhance as time goes by.
« Last Edit: April 30, 2014, 04:21:21 AM by jwiz168 »

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 936
    • View Profile
Re: Email service DAC for the use by other DACs ?
« Reply #4 on: April 30, 2014, 05:30:30 AM »
I do remember discussion at some point about Keyhotee to traditional email gateways...

There we go:

It's possible to set up gateways to act as proxies and forward between traditional email and Keyhotee, but you'd have to trust the person running the gateway to actually deliver your messages, and with access to read your messages if you didn't encrypt them.