4 ms·

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

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?

jbri 16y ago
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.
- RiderOfGiraffes 16y ago
  So I don't see what you're adding. You guarantee that people I know can get through, which I already do with whitelists, and you require content based filtering on the rest, which I already do. So I don't really understand how what you're proposing makes a difference.
- vacri 16y ago
  How does Ben know that the guy previously emailed adam, anna and berry? Shouldn't Adam, Anna and Berry be concerned about their email privacy if Ben just reads their email on a whim?
derefr 16y ago
Spam filtering is still required in this case, by definition: potential clients and spammers are not disjoint sets. Any completely unknown sender who sends you a message has no metadata attached to their message which may enable trust rating; therefore, the only thing you'll be able to judge them on is the quality and relevance of the message content itself. 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.

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?

jbri 16y ago

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.

RiderOfGiraffes 16y ago
So I don't see what you're adding. You guarantee that people I know can get through, which I already do with whitelists, and you require content based filtering on the rest, which I already do. So I don't really understand how what you're proposing makes a difference.
vacri 16y ago
How does Ben know that the guy previously emailed adam, anna and berry? Shouldn't Adam, Anna and Berry be concerned about their email privacy if Ben just reads their email on a whim?

derefr 16y ago

Spam filtering is still required in this case, by definition: potential clients and spammers are not disjoint sets. Any completely unknown sender who sends you a message has no metadata attached to their message which may enable trust rating; therefore, the only thing you'll be able to judge them on is the quality and relevance of the message content itself. 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.