Fork me on GitHub

would it be possible to have a streaming service that is totally decentralized relying only on peer to peer bandwidth sharing?


peertube ?


ah, peertube is sure interesting. but i had a 'streaming' network in mind


compensating the bandwidth providers with crytpotokens?

Martynas Maciulevičius09:06:54

The problem with streaming is that your data has to fit into a single computer box. If you see things like Ethereum they have data amounts that fit into a single box (HDD it's still intended to be in one machine; and they also do trusted chain snapshots). The more data that you want to stream the less likely it will fit into a single box. To mitigate this you could rely on solutions like IPFS to provide actual streams and put the digests on your chain which would fit into a single machine. But then you wanted a stream service and not file delivery system which means that you need to chunk these files and calculate hashes on those chunks (this will also increase download speeds). So now you'd be in a chunking business. How to find a good chunk-size balance to reduce the size of the paid chain but also keep the speed of the downloaders? (Assuming you would be sending your stream to more than one person).

Martynas Maciulevičius10:06:20

If it's a video stream then you can do quality conversions. So when you have many chunks then you can downscale them and interleave the video streams to the user. If these streams are financial data then it's probably something different.


i meant streaming in particular


the streamed video content itself won't be persisted anywhere


only data about the nodes that provided bandwidth & money allocated to them for their service


so i imagine the storage requirements would be miniscule


but i'm just speculating, there might be something i'm missing

Martynas Maciulevičius18:06:52

Twich lags for about a minute. I have no idea about what kind of "won't be persisted" you talk about :thinking_face: You could delete your files "soon". But I'm not sure what kind of "not persisted" you talk about. When data is sent it's still stored in wires and in routers. Even if you think it "moves" it's still saved. So probably you would want to have 1-minute chunks that you would load from the storage.


one of the (many) reasons I get annoyed with cryptocurrency projects that try to do the "what if X, but decentralized and with a token" thing is because they suck all the oxygen away from efforts to achieve similar goals without the waste of permissionless blockchains. one such project that aims to make data content-addressable in a way that would support a distributed approach to data access that cryptocurrencies is It's had substantially more thought put into it by people actually involved in the design and implementation of the modern networking stack than the crypto-token hype projects that claim to do similar things.


A token is just a value expression mechanism that predates cryptocurrencies and the internet and.. well, a lot of things. Using cryptography and distributed networking to exchange tokens does not necessarily make tokens a bad idea and using tokens doesn't make an idea bad.


About which point do you disagree?

Ben Sless13:06:01

Which crytpo project is there which tackles ndn?


Filecoin is the one that comes to mind:


Is it basically just content-addressed networking?


I think Filecoin is just an incentive layer built on top of NDN and IPFS seem similar.


But from a quick glance, I can't see what NDN does to encourage the named content to remain hosted. I guess it's out of scope, and that's the particular aspect of such an architecture that Filecoin aims to solve.


the two issues are not at odds with eachother


as a matter of fact what you're describing is each packet being treated somewhat as a NFT


blockchain systems on the other hand are a protection against 'network partitioning' in order to emulate 'ownership' & 'binding contracts' qua building a totally ordered immutable log


i don't see how anyone would be incentivized to run a service such as providing bandwidth, if they're not compensated for it


it just won't happen


data may be really expensive both in terms of its content and its delivery costs


so what you describe misses the crucial business aspect


one vision is that of a multitude of data producing/consuming nodes that meet in a data market


right now ipfs is a protocol that provides data units as globally addressed entities


yet, the storage costs mean there is a market for providing ipfs data


If "missing the crucial business aspect" means decoupling the questions of "how to do it" and "who will pay for it" in considerations of network + technical architecture then I'm all for it. It's fine if the technology doesn't answer that question, just like it's fine that I don't have to worry about who's paying for users' hardware when I release a software library. Experience is proving to show that attaching a cryptocurrency to a distributed network is a great way to flood it with scammers and create a financial bubble at record speeds. I'd rather not hitch my star to that wagon.


A regular old market can and will continue to meet the storage needs of most people for some time yet. Cryptocurrencies are having a pretty difficult time showing that the "decentralization" they provide does anything other than create new intermediaries while wasting loads of computational resources while providing a network that is far less stable and secure than conventional institutions.


I think the "how to do it" and "how to pay for it" are orthogonal issues and it's not a bad thing that there is effort in both places. Crypto is definitely rife with scammers but that doesn't change the fact that at its core, the idea is simply the combination of distributed networking, cryptography, and game theory.


This is the last thing I'll say on this: if we're going to make the case that the problem is in the implementation rather than the core of the idea, I wonder exactly how many more people need to get scammed as cryptocurrency hackers "test in production" before someone finally lands on an implementation that's not a complete mess.


I'm just making the case that the idea is an abstract thing and its outcome is difficult to predict. Happy to continue the conversation anytime you are @UFTRLDZEW 🙂


there being a lot of scams does not deter from the value of blockchains.


this whole tech is in its infancy & we have not even begun to imagine the fruits it will bear


look at the issue of identity for instance. right now user identity is local & walled behind a trusted system with control over it being delegated to the user by the trusted entity.


soon people will realize the power of public-key cryptography and global notion of identity that does not depend on any particular system.


it will turn the "users" at the mercy of trusted systems into "actors" with full control over their identity, data, privacy, ...


not to mention decoupling of the notion of 'legal binding' from geopolitical jurisidctions.


one could make the same argument regarding "scammers" about indie game developers too.


with the rise of platforms like steam & crowdfunders & ... a massive number of scammy garbage was produced


but noone in their right mind would deny that the value created dwarfs the garbage output


in any case, i don't see people pointing fingers about the travesty of current financial systems & judicial frameworks, economical crisis, underdeveloped world sinking deeper into debt, upcoming wars & ...


the whole amount of capital in crypto is miniscule in that regard


million-times the whole market-cap of crypto is wasted by institutional investors & financial manipulators


yet for some reason people get more annoyed about a dog nft


a lot of tech people fail to appreciate crypto because of limited knowledge about political economy


'decentralized' identity is an instructive example: the people working on it appear to completely lack a consistent concept of what "privacy" and "control" even mean, as argued convincingly by Molly White: > People are already talking about capturing enormously sensitive information in digital form, issuing attestations about other individuals either with or without their consent, and, in some cases, recording all of these things to immutable blockchains where they would be stored indefinitely > I personally do not want to have sensitive information about individuals recorded on an immutable tamper proof log that lacks anyone that can be appealed to when things (inevitably) go wrong. There's a lot that's wrong with existing institutions, but I'd rather not create new ones with flaws frozen in time by code and immutable ledgers.


The Buterin quotation speaks for itself.


one doesn't have to listen to any authority btw


cryptorevolution is not driven by voluntarist will of a few heroes


matters of simplicity & market forces are at work


Decentralized ID can become more interesting when zero knowledge proofs are applied.


Sorry. the state is not going away, regardless of where the data is stored. we've had machines that perform contracts for quite a while;t=2026 in every contract, there are not 2 parties involved, there are (at least) 3 (the state)

⬆️ 1
👀 1
Ben Sless03:06:19

You can have consent centric networking and an identity model without crypto :man-shrugging: But it might have baggage attached 🙂

Ben Sless15:06:03

While the last thing I want is a government provided and controlled internet, I agree regarding Tue incentive structure. I just fall on the side that sees the internet as fundamentally broken. Money may be fake, but all abstractions are. They can still be useful, especially if we don't break them down to nonsense


I haven't watched that video yet but intend to. The state definitely is not going away, but it will continue to play catch-up with technological innovation. I like the idea for the long term. Things just tend towards openness. The ability to produce and publish is reaching more people over time. I think it's natural that along with our ability to share ideas, we will be able to make value expressions about those ideas, and the entire medium by which we do so won't necessarily be fully controlled in a top-down manner.


I just had one of those "why didn't I google this before" moments... how to tell git rebase to always solve merge conflicts in a fixed direction (for my use case it's the opposite strategy than the article's, i.e. -Xours)

👍 2

I've found much value in taking many more much smaller steps. So I'd like to recommend GeePaw Hill's podcast about just this!


Are you taking small steps when you're coding? Or large steps? Any disadvantages with small steps?


Interesting. Which podcast in particular, do you refer to?


For me, most of the time, I find myself making steady progress with tiny baby steps in design and coding. I usually write down todo list for my coding tasks to force me to think deliberately what are the optimal steps to approach coding. However, rarely, when I'm in "flow" or too tired to be deliberate, I'll just code. The outcome is uneven. Sometimes, exceptionally good, but usually, just lousy.

👍 1
Martynas Maciulevičius17:06:03

It depends on the stage of the project. I think in the beginning you don't care that you have a lot going on. Also if it's a large refactoring you simply can't move in small steps.


The last one is which I don't find it relevant to coding steps. That's why I asked.


Oh, yeah, I guess that one was more about steps for changing organizations.


After listening to the podcast 130. I know now that his concept of "steps" has special meaning of developing software from a working (steady) to another working (steady) state. It's not the usual steps of task execution.


Yup. Do you find that definition helpful?

Drew Verlee21:06:48

What are the reasons to coerce an http response body to a byte stream vs byte-array vs text/string as is an option with http-kit here? I imagine that text means you have to read the entire thing into some memory space, which might be problematic (though i would image controlling the payload is mostly a networking task?).


Byte Stream • doesn't require reading the full response into memory • can partially read or completely ignore contents • allows for techniques like long polling • allows for backpressure Byte array • can ignore the mechanics of reading the response and just deal with full response once it's ready string • assumes text (not all responses are text) • potentially, assumes a particular string encoding.

👍 2
Drew Verlee22:06:31

thanks for the explanation. I'm not sure which will matter in my case yet so ill probably start with string.


yea, as long as you're expecting text, then that's probably a good start

Cora (she/her)22:06:06

byte streams also can make bytes available sooner (when paired with a streaming decoding of whatever you're dealing with)


adding: "byte stream" isn't common terminology


InputStream is


InputStream can also block when you read them, tying up the handling thread

👍 1
Cora (she/her)22:06:28

total throughout does not necessarily change (and sometimes is worse!) but sometimes that little bit of latency matters

Cora (she/her)22:06:59

(but it rarely does, in my experience)

👀 1