signed multifeed support?

[telamon]

Hi!
I'm working on something that would enable me to free myself another tiny bit from the cloud,
and I'd really love to be able to pay for dedicated replication on a service like hashbase.

This prototype illustrates the replication mechanism: https://github.com/telamon/multifeed-sigrid

Is signed-multiwriter support completely out of scope for hashbase?
(If not, could someone point me in the right direction?)

[pfrazee]

When multiwriter support is added to Dat, Hashbase will gain support as well. Right now we're not planning to add anything else.

[telamon]

@pfrazee Yeah if i understand correctly the multiwriter support is on hyperdrive level? (hypercores are still single-writers?)

I'm working on a similar thing but on a few layers higher, that enable other patterns like ad-hoc writer control, or application defined replication control.
The use case i had in mind when opening this issue was:

1. Sign up for hashbase, provide my public key from my personal signing-pair.
2. Any feed i sign offline or online can be automatically be replicated to my hashbase account without having to manually add each individual feed key.

I've sadly failed to find the main "multiwriter" issue, would love to see how you guys are approaching the subject could you maybe point me in the right direction?

[pfrazee]

@telamon You're correct that multiwriter is part of hyperdrive, and so if you want a higher level protocol, you'll need Hashbase to do two things:

1. Support general hypercores (it doesnt currently)
2. Have some method of knowing which other hypercores are related and need to be replicated with the main one

I think what you're asking for is very reasonable and it's where I want to go because hypercore can express structures that hyperdrive can't. I don't know the timeline for enabling it, though. All I can say is: I'm totally into what you're trying to do, I just can't hit it yet.

There's no issue for multiwriter in hashbase yet. We're still working on that in the dat protocol, and that actually means that maf is heads-down on it, but we're not publicly tracking it yet.

[telamon]

@pfrazee

1. Support general hypercores (it doesnt currently)

That's the question I've been trying to answer, without yet diving down into hashbase's source.

2. Have some method of knowing which other hypercores are related and need to be replicated with the main one

This is what I've recently contributed to on my multifeed fork: https://github.com/telamon/multifeed/tree/feature/repl-api#replicaton-policies
But it depends on the 1st PR I sent to noffle which is still under review
kappa-db/multifeed#18

So I figured that maybe I should hack a bit on hashbase while waiting for the world to start spinning again. Given the assumption that you guys actually want to have multifeed support in hashbase :D

[pfrazee]

Given the assumption that you guys actually want to have multifeed support in hashbase :D

I'd need to look into how multifeed works. If it's not super general, it's not really a general solution to issue 2; then it's just another data structure like hyperdrive.

[telamon]

No it's not a datastructure, there are no hypercores created or written during replication, it's just a hyper-protocol enhancement using hyperproto's extension api.
Basically I've added a non-blocking channel for core exchange that let's the application decide which cores to replicate.

which in hashbase's case would make sense to use the signature-replication policy that i linked to in my original question. As a user I'd generate a set of personal keys; uploaded my public key to hashbase and then any feed that is accompanied by a signature made from my private key could safely be accepted and counted towards my user-quota on hashbase