51–55 of 55 posts
But what the press does like is hearing about how existing products have made businesses successful. These stories are about the success of the business as a result of the product, which is the thing that is changing for companies with more static products that are very successful.
Earlier quoted context omitted.
You will never be able to stop spam (I assume you mean email). A few years ago I realized this when looking through my logs I saw emails to ... bob@domain.com ben@domain.com berry@domain.com ... etc Blindly trying the most common. I knew then that if I wanted the account name ben I could never 'solve' spam on top of our general email system we have today.
For all those who downvoted this how do you 100% 'solve' spam?
Earlier quoted context omitted.
Public-key channels over e-mail. Think about how your body works: each cell has certain receptors (a key) and only reads data from objects that are shaped to plug into those receptors. Thus, random messages can float around in the bloodstream without every random cell trying to interpret them. Similarly, we could have an actual "inbox" (a bloodstream) that never gets displayed, and then channel-specific inboxes that…
I didn't fully understand that explanation, but I'm trying to see how a potential client can contact me using the system you suggest. And if a potential client can, why can a spammer not?
However, assuming ubiquitous identity servers, of the kind Diaspora is trying to enable, each identity server could be subscribed to a feed of updates for a respective channel key. So, for example, you could have an identity server at work from which other employees could pull your current "work" channel key, or an identity server at a hackathon meet-up from which other people who came to the meet-up could pull your current "meet-up" channel key. Then, people who contacted you would be contacting you with the trust score of the identity server pre-applied (you'd assign your work identity server a high score, because only employees may be members, while the meet-up score would be lower because anyone could show up and sign in, etc.) If you only want to deal with people you've physically met, you can just draw a line saying to discard messages below a certain trust score, and be done with it.
If not, though, channels are still a helpful complement to spam filtering, as each channel could have its own spam filter trained on channel content—so something that would be perfectly fine in a "work.offtopic" channel would be considered spam in a "work.ontopic" channel. Because people would likely have multiple means of contacting them (you'd have access to most people you actually knew through multiple channels), individual channels could be much harsher about rejecting content—probably just silently discarding it for everyone but the sender, and either acknowledging the rejection to the sender, or just saying nothing. (If clients sent a message to all relevant channels simultaneously, and messages from different channels with the same ID were re-combined for other clients, this wouldn't be so much of a problem.)
Any extension to this concept would simply be sticking an identity server in a new place: one sitting on each person's phone or computer providing temporary access to a "proximity channel" that constantly shifts (so as soon as you go out of range, you're unsubscribed from the identity server and can no longer send messages), topic-oriented free-to-join identity servers (basically equivalent to IRC servers, except that they don't have to handle message routing themselves), and so on.
At my old work, our basic software showed a series of line graphs crossing a page in realtime. Compared to the previous available tech (paper pen printers) it's Big and New.
Comes version 2 of the software and it has many refinements - antialiasing and smoothing algorithms to make the data look nicer and more interpretable but with no loss of significant detail; improved analytical algorithms with tighter results; reduction in data stored per unit of information; so on and so forth. But the users don't see this, and certainly don't think it's "much more" than version 1 - "Shouldn't this be a patch? Why should we have to purchase it again for v2?"
That job also taught me that what users want and what devs think users want are frequently miles apart.
Earlier quoted context omitted.
I didn't fully understand that explanation, but I'm trying to see how a potential client can contact me using the system you suggest. And if a potential client can, why can a spammer not?
Here's one way: The guy that tried adam@example.com, anna@example.com, berry@example.com etc., sending basically the same message to each, before trying ben@example.com is probably not a "potential client". Then you get into the spam-filtering based on content, which is already successful at preventing massive amounts of spam.
Shouldn't Adam, Anna and Berry be concerned about their email privacy if Ben just reads their email on a whim?