Matthew John Toseland writes:
> On 16/09/17 08:31, Arne Babenhauserheide wrote:
>>
>> Matthew John Toseland writes:
>>> The above is slightly inaccurate. For a genuine user, the third step
>>> starts off as a bundle, then later becomes a
On 16/09/17 08:31, Arne Babenhauserheide wrote:
>
> Matthew John Toseland writes:
>> The above is slightly inaccurate. For a genuine user, the third step
>> starts off as a bundle, then later becomes a broadcast. We enforce the
>> scarcity and popularity requirements in
Matthew John Toseland writes:
> The above is slightly inaccurate. For a genuine user, the third step
> starts off as a bundle, then later becomes a broadcast. We enforce the
> scarcity and popularity requirements in both stages.
Doesn’t enforcing scarcity at the bundle
On 15/09/17 20:51, Arne Babenhauserheide wrote:
>
> Matthew John Toseland writes:
>> Specifically, the process for a scarce *insert* will be:
>> 1) Is the key popular?? We can tell this from how many peers are
>> subscribed to it in the ULPR table. If not, kill the
Matthew John Toseland writes:
> Specifically, the process for a scarce *insert* will be:
> 1) Is the key popular?? We can tell this from how many peers are
> subscribed to it in the ULPR table. If not, kill the request; we only
> provide protection for popular
On 14/09/17 22:18, Arne Babenhauserheide wrote:
>
> Matthew John Toseland writes:
>> On 14/09/17 17:33, Arne Babenhauserheide wrote:
>>> I think the core problem is that I don’t quite understand what you’re
>>> proposing. Bundles I understand, but I don’t understand how
Matthew John Toseland writes:
> On 14/09/17 17:33, Arne Babenhauserheide wrote:
>> I think the core problem is that I don’t quite understand what you’re
>> proposing. Bundles I understand, but I don’t understand how the scarce
>> SSKs change routing.
>
> They don't.
On 14/09/17 17:33, Arne Babenhauserheide wrote:
>
> Matthew John Toseland writes:
>> On 13/09/17 21:23, Arne Babenhauserheide wrote:
>>> Matthew John Toseland writes:
Proposal 0: Bundles
---
>>> Do I understand it
Matthew John Toseland writes:
> On 13/09/17 21:23, Arne Babenhauserheide wrote:
>> Matthew John Toseland writes:
>>> Proposal 0: Bundles
>>> ---
>> Do I understand it correctly that this means that all inserts from a
>> given
On 13/09/17 21:23, Arne Babenhauserheide wrote:
>
> Matthew John Toseland writes:
>
>> On 12/09/17 22:34, Arne Babenhauserheide wrote:
>>>
>>> Matthew John Toseland writes:
But we need *something* in this approximate area.
>>>
>>> I
Matthew John Toseland writes:
> On 12/09/17 22:34, Arne Babenhauserheide wrote:
>>
>> Matthew John Toseland writes:
>>> But we need *something* in this approximate area.
>>
>> I fully agree with that. I think however that we need to be
On 13/09/17 19:56, Matthew John Toseland wrote:
>
>
> On 13/09/17 19:51, Matthew John Toseland wrote:
>> On 12/09/17 22:34, Arne Babenhauserheide wrote:
>>>
>>> Matthew John Toseland writes:
But we need *something* in this approximate area.
>>>
>>> I fully agree
On 13/09/17 19:51, Matthew John Toseland wrote:
> On 12/09/17 22:34, Arne Babenhauserheide wrote:
>>
>> Matthew John Toseland writes:
>>> But we need *something* in this approximate area.
>>
>> I fully agree with that. I think however that we need to be careful not
>>
On 12/09/17 22:34, Arne Babenhauserheide wrote:
>
> Matthew John Toseland writes:
>> But we need *something* in this approximate area.
>
> I fully agree with that. I think however that we need to be careful not
> to require user interaction for that. Users already
Matthew John Toseland writes:
> But we need *something* in this approximate area.
I fully agree with that. I think however that we need to be careful not
to require user interaction for that. Users already added the friend, we
can’t require more than maintaining the
On 11/09/17 22:48, Arne Babenhauserheide wrote:
>
> Matthew John Toseland writes:
>> Applied to spam, for example, we could justify banning somebody by
>> showing some of his messages.
>>
>> Does it still allow for spam amplification? Probably, if we immediately
>>
Matthew John Toseland writes:
> Applied to spam, for example, we could justify banning somebody by
> showing some of his messages.
>
> Does it still allow for spam amplification? Probably, if we immediately
> propagate inserts to everywhere. But maybe we can resolve the
On 03/09/17 21:01, Matthew John Toseland wrote:
> On 03/09/17 20:53, Arne Babenhauserheide wrote:
>> Hi toad,
>>
>> Matthew John Toseland writes:
>>> Thoughts? I'm not a dev any more, but thinking about Bitcoin and other
>>> stuff maybe there are some ways forward that
On 03/09/17 20:53, Arne Babenhauserheide wrote:
> Hi toad,
>
> Matthew John Toseland writes:
>> Thoughts? I'm not a dev any more, but thinking about Bitcoin and other
>> stuff maybe there are some ways forward that we've missed...
>>
>> Dispute resolution, spam and
Hi toad,
Matthew John Toseland writes:
> Thoughts? I'm not a dev any more, but thinking about Bitcoin and other
> stuff maybe there are some ways forward that we've missed...
>
> Dispute resolution, spam and distributed data structures
>
On 03/09/17 18:31, Matthew John Toseland wrote:
> Thoughts? I'm not a dev any more, but thinking about Bitcoin and other
> stuff maybe there are some ways forward that we've missed...
>
> Dispute resolution, spam and distributed data structures
>
21 matches
Mail list logo