Yaacov Akiba Slama [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-09 📝 Original message: [Sorry: re-sending again ...
📅 Original date posted:2019-11-09
📝 Original message:
[Sorry: re-sending again in plain text]
On 08/11/2019 16:15, Joost Jager wrote:
>
> > The goal of this pre-payment proposal is to remove the need for
> > trusted parties
> >
> > Trust isn't the right word. It is a level of service that you
> provide
> > to your peers. If nodes are cognizant of the fact that the level of
> > service they receive goes down if they forward spam, they will be
> > careful on the incoming side. Require peers to build up a
> reputation
> > before increasing the inbound limits that apply to the channels
> with them.
>
> We can learn from the current situation in emails, that a system
> based
> on reputation tends to concentrate the power in the hands of few
> big and
> strong actors (gmail and co). If we have from the beginning a
> mechanism
> to fight against spam by paying to send message, we can perhaps
> have a
> really distributed system which cannot be censured.
>
>
> Can you elaborate on this a bit further? If you consider rate limiting
> to be a form of censoring, then you can still censor if there is a prepay.
There are situations when lot of people need to send each other lot of
messages in a small period of time, in protests for instance. In this
case, people are ready to pay a little to communicate. It's true that
they can be censored even when paying for messaging, but in this case,
it's a voluntary (and politic) decision. But when using a rate limiting
mechanism, it's an economic decision with politic implications.
>
> I am not too familiar with the current state of email servers, to what
> extent power is concentrated now and how that evolution translates to
> Lightning.
Currently, if you install a smtp server in you home computer or in a
server you rent and you try to send an email to someone with an email
from any big provider, it will be marked as spam, because you need to
have a good "reputation". And if you try to send so called "marketing"
emails, you'll be marked as spammer even if the same emails sent by big
providers are not rejected. This is the effect of using any reputation
system. The path from reputation to propaganda is very short.
> One difference is that afaik emails don't traverse a path through
> multiple mail "nodes". Another is that inboxes of users are very
> centralized (gmail and co).
I can imagine a system where people who want to use the messaging system
based on Lightning will have to open a channel to big nodes in order to
be able to reach their recipient. In this case, those big nodes can
censor as they want because they have access to a lot of metadata.
Published at
2023-06-09 12:57:13Event JSON
{
"id": "3957a1bee8cb5552722cbbf53c2e01d18e58668a6c973196494bfc987cd60f3d",
"pubkey": "13fd0434c7ac300f7a468a5ad9464b7b94e8b03d7ae88259f3de3a84422822fd",
"created_at": 1686315433,
"kind": 1,
"tags": [
[
"e",
"0c91e21e034533f122e94b0fd3031654ae905512e27a1262e64ae8c7923a76b8",
"",
"root"
],
[
"e",
"e9208bb030313eded850b2dadf4cca6967857a8e748451c773c2f5ef11877caf",
"",
"reply"
],
[
"p",
"13fd0434c7ac300f7a468a5ad9464b7b94e8b03d7ae88259f3de3a84422822fd"
]
],
"content": "📅 Original date posted:2019-11-09\n📝 Original message:\n[Sorry: re-sending again in plain text]\n\nOn 08/11/2019 16:15, Joost Jager wrote:\n\u003e\n\u003e \u003e The goal of this pre-payment proposal is to remove the need for\n\u003e \u003e trusted parties\n\u003e \u003e\n\u003e \u003e Trust isn't the right word. It is a level of service that you\n\u003e provide\n\u003e \u003e to your peers. If nodes are cognizant of the fact that the level of\n\u003e \u003e service they receive goes down if they forward spam, they will be\n\u003e \u003e careful on the incoming side. Require peers to build up a\n\u003e reputation\n\u003e \u003e before increasing the inbound limits that apply to the channels\n\u003e with them. \n\u003e\n\u003e We can learn from the current situation in emails, that a system\n\u003e based\n\u003e on reputation tends to concentrate the power in the hands of few\n\u003e big and\n\u003e strong actors (gmail and co). If we have from the beginning a\n\u003e mechanism\n\u003e to fight against spam by paying to send message, we can perhaps\n\u003e have a\n\u003e really distributed system which cannot be censured.\n\u003e\n\u003e\n\u003e Can you elaborate on this a bit further? If you consider rate limiting\n\u003e to be a form of censoring, then you can still censor if there is a prepay.\nThere are situations when lot of people need to send each other lot of\nmessages in a small period of time, in protests for instance. In this\ncase, people are ready to pay a little to communicate. It's true that\nthey can be censored even when paying for messaging, but in this case,\nit's a voluntary (and politic) decision. But when using a rate limiting\nmechanism, it's an economic decision with politic implications.\n\u003e\n\u003e I am not too familiar with the current state of email servers, to what\n\u003e extent power is concentrated now and how that evolution translates to\n\u003e Lightning.\n\nCurrently, if you install a smtp server in you home computer or in a\nserver you rent and you try to send an email to someone with an email\nfrom any big provider, it will be marked as spam, because you need to\nhave a good \"reputation\". And if you try to send so called \"marketing\"\nemails, you'll be marked as spammer even if the same emails sent by big\nproviders are not rejected. This is the effect of using any reputation\nsystem. The path from reputation to propaganda is very short.\n\n\u003e One difference is that afaik emails don't traverse a path through\n\u003e multiple mail \"nodes\". Another is that inboxes of users are very\n\u003e centralized (gmail and co).\n\nI can imagine a system where people who want to use the messaging system\nbased on Lightning will have to open a channel to big nodes in order to\nbe able to reach their recipient. In this case, those big nodes can\ncensor as they want because they have access to a lot of metadata.",
"sig": "2678b63fc978446b90357c6bc31cc285c27d299d733df30682c3c4cd1fd9067f25cf93477c897feef8efb47254e2f6a608fdff2679c8acb58163c1827a2b1d9c"
}