How are we mitigating Sybil and Denial of Service attacks? Is there any way to guarantee quality of service requirements? Suppose if there are some nodes that have very low bandwidth, can a user just choose not to get data from them if it’s available with someone else, how would they even know?
Interested observer here so probs way off but have some links that may help. I remember this topic being covered in some previous YouTube AMA sessions but I can’t remember precisely which ones, woah if they were indexed like https://askgaryveeshow.com that would be awesome!
There’s some discussion here which may help:
Also this blog post provides some base info:
If my own understanding is anywhere near correct, much of the service requirements question you ask will be down to service providers to build, hence the value in a service such as holo.host. In that example they provide part of the quality guarantee through developing and providing specific hardware, much like Apple do, then it’s their ongoing work to guarantee the level of bandwidth by doing what you say - manage where to get the data from.
I would imagine there will be more niche providers than holo.host spring up for particular requirements, because of course some applications will care about these issues and some not so much.
Great question, I look forward to learning more and hope I’ve at least provided some further info than you already had.
I meant that since each user can and would store and serve app data how would we ensure QoS?
holo.host would be good but shouldn’t we get a good experience without relying on it at all?
I also have concerns about how holoport can mine app data and log IP addresses, eventually gathering sufficient data to narrow down a user’s identity.
Also, I haven’t yet seen any mention of DoS attacks. If a user is responsible for his own compute one could censor him just by DDoSing his IP. But there are other ways to dramatically slow down the entire network, like a churn attack.
What about deferring user compute to someone else for certain actions like receiving credit?
I imagine a decentralised way to ‘rate’ node QoS in addition to proofs of misconduct, so that the user can set a minimum rating they prefer and we keep looking for better nodes until a timeout at which point we fallback to whatever we have.
I am trying to figure out live streaming in a holochain consistent way. I am expecting to need to build an overlay multicast network that keeps track of directed graph of nodes for efficient delivery of real time data. But I am kinda lost on how to go about achieving these daunting tasks.
It would be great if I could just avoid this and achieve what I want. Please help.
I think the very nature of decentralised, distributed hosting does indeed pose these interesting questions and as I mentioned, individually many of these topics have come up time and again in the AMAs, however the only way to find out is to watch them all, they’re on YouTube 
I also think this is “the fun” of what we have to look forward to - one of the main issues I see is we are so used to what we have however that’s been built upon current architecture, so we don’t have the answers yet for how to replicate these in the new - and in fact whether they will work because most of the services the masses use exist because of the very business models we are trying to change.
From what I’ve seen, your point about keeping track of the nodes is closest to what I’ve heard being talked about - using Holochain as the mechanism of metadata as opposed to necessarily the delivery system, which is a little abstracted from what you’re saying but along those lines of thinking.
As for DDosing I do know this has been addressed many times before as well but not really my area, I can’t figure out DNS and redirecting https let alone DDos stuff lol
…oh, and yes as far as identifying people on holo.host then yes, I do believe holo.host will be a target for the censors, I guess hence why I was mentioning not using HF as that’s tied to holo.host when actually you may want your own network, and that’s just using Holochain along with your version/fork/whatever of Holo’s code, or internal if say a local mesh network as described in the latest YouTube video showing how local energy networks could share internet access as well as energy.
Blockquote
From what I’ve seen, your point about keeping track of the nodes is closest to what I’ve heard being talked about - using Holochain as the mechanism of metadata as opposed to necessarily the delivery system, which is a little abstracted from what you’re saying but along those lines of thinking.
Yeah that’s what I figured as well but the problems remain.
1 Like
AMA No.51 ? If not could you link that video?
Well in terms of discoverability of who did what, perhaps the example of that chat app they did in the recent developer training week thing where it doesn’t actually store any data only transports it might fit in well when it comes to streaming.
IIRC it’s in or towards the Q&A in the second half where he talks about the fact that a side-effect of sharing energy amongst your neighbours is you have the network in place to also share the network, thus being able to give birth to the bottom-up mesh networking we all dream of. When he says it, there’s a short but wonderful silence where the penny drops
So why is holochain needed for ephemeral chat in the first place?
Do you mean Elemental chat?
Well without looking as I need to go attend to my cooking before it burns… perhaps it’s because if you don’t store anything and the node’s not around at the time when you send the message then it doesn’t work well as a proper ‘chat’ app.
Sorry, my brain isn’t working properly - I had in my mind “burner chat” and didn’t notice it was called ephemeral chat - I lost my glasses the other day so everything’s fuzzy and I’m only focusing on the text I need to as my brain is being overloaded trying to manually correct my lazy eye as well as interpret the letters lol #tmi
Why is it needed? Well, it’s decentralised burner chat, it’s an example of what can be done with a decentralised, distributed network. Which could feasibly be done with a network of indieweb/etc. however I imagine it’s a whole load faster and more efficient when using one language and one app.
I was reading the above paper. It seems that if we keep “shadows” that keep track of neighbour info of every peers then we might be able mitigate a chunk of issues.
AFAIK holochain already forces many peers to independently verify the chain of every peer. What if we make them also keep track of their neighbours?
(This isn’t the complete solution by any means)