<joepie91>
infinisil: fwiw, I'm much more interested in the underlying concepts than in the implementation ("filecoin")
<infinisil>
Agreed
<infinisil>
More projects could profit from its findings
<joepie91>
infinisil: my opinion of IPFS has actually soured quite a bit since Filecoin started being a thing, since it seems to be happening at the cost of IPFS/libp2p as application components
<joepie91>
I'm now looking into implementing my own lookalike protocol for a project
<joepie91>
because IPFS is just uselessly underdocumented and underimplemented
<joepie91>
and it seems to be changing to suit Filecoin specifically
<infinisil>
lookalike protocol? An IPFS like thing?
<joepie91>
as a component of something bigger, yes
<joepie91>
this was the original promise behind libp2p and IPFS
<joepie91>
reusable bits of P2P infra
<joepie91>
for custom application development
<joepie91>
that vision seems to have been... lost
<joepie91>
in favour of Filecoin specifically
<infinisil>
Hmm, I'm not sure, IPFS seems kinda incomplete without availability guarantees
<joepie91>
it's really not, if you correctly understand what it is
<joepie91>
IPFS is essentially designed as 'bittorrent, but for embedded application use'
<joepie91>
for which its design is great
<infinisil>
What are you planning to use IPFS for without availability guarantees?
<joepie91>
opportunistic data replication and distribution, mostly
<lejonet>
To take over the world! (not guaranteed)
<joepie91>
lol
<infinisil>
So, replicate if it's there but it doesn't matter if it's not there anymore?
<joepie91>
infinisil: the specific project I have in mind here is a 'curated filesharing' project
<joepie91>
ie. based around collections of shared data
clefru has joined #nixos-chat
<joepie91>
decentralized
<lejonet>
Interesting idea
<clefru>
blockchains \o/
<joepie91>
this doesn't require availability guarantees, in and of itself
<joepie91>
[11:28] <infinisil> So, replicate if it's there but it doesn't matter if it's not there anymore?
<lejonet>
lol
<joepie91>
pretty much
<infinisil>
But then there's the problem with every torrent, low amount of peers over time
<joepie91>
yep, which is the same inherent problem that IPFS has, but that's not a problem I intend to solve :)
<lejonet>
That is the problem with decentralisation overall
<joepie91>
the problem can be minimized somewhat with IPFS due to shared block storage
<joepie91>
whereas with torrents, the same data in two different torrents is totally separate
<joepie91>
(this is why, conceptually, it's nice to use IPFS as a shared P2P layer for custom applications)
<infinisil>
Well I guess torrenting works, so IPFS will work in of itself too
<joepie91>
(as all those applications can essentially share the same 'data space')
<infinisil>
But I'd like my torrents not to disappear
<joepie91>
sure, but that is just an unsolved problem on a technical level; the only existing solutions are political and/or social in nature
<infinisil>
Oh how about this
<joepie91>
it may always remain an unsolved problem on a technical level, too :)
<infinisil>
A combination of a centralized server that always provides at least 1 seed, and IPFS
<joepie91>
sure, that is one case of opportunistic decentralization
<joepie91>
problem with that isn't the technical side, the technical part is easy
<joepie91>
the problem is that unless you frame it correctly, the centralized server operator will come to feel less responsible for availability
<joepie91>
and unless you have solid monitoring, they will discover quite late when things are down/gone
<joepie91>
this is kind of the underlying issue with storage and replication; it's not _really_ a technical problem
<joepie91>
it's a fuzzy human problem :)
ashgillman has quit [Ping timeout: 264 seconds]
<infinisil>
True, so in the end you still only have the security of the number of seeds (or lack thereof)
ashgillman has joined #nixos-chat
<infinisil>
And the server might not be there anymore in 10 years
<joepie91>
right
* infinisil
is actually supposed to pay attention to the lecture
<joepie91>
infinisil: which lecture? :P
<infinisil>
Compiler Design
<joepie91>
ahh
<infinisil>
Currently about bottom-up parsing
<joepie91>
uni/college/something?
<infinisil>
bachelor computer science at ETH University
<infinisil>
:)
<joepie91>
right :P
<joepie91>
man
<joepie91>
my mind is corrupted
<joepie91>
I can't read "ETH" as anything other than "Ethereum" now
<infinisil>
Haha
<joepie91>
I'm... not happy about this :|
<infinisil>
It confused me the first time i read about Ethereum
<joepie91>
I have the unfortunate curse of being familiar with pre-Bitcoin decentralization research and design, and also being familiar with a lot of the tech behind current cryptocurrencies, and so I both understand the tech and realize how incredibly flawed and naive almost all of it is...
<joepie91>
and I also run in some circles where all of this regularly comes up
<joepie91>
there is no escape...
<infinisil>
Whew, well I only just dipped my toes in IPFS and just read a bit about blockchains
<joepie91>
infinisil: my general advice would be: don't assign too much value to either of those
<joepie91>
IPFS is conceptually interesting, but the tech isn't particularly novel, it's almost exactly like bittorrent in many ways
<joepie91>
it's just put together in a way that's more suitable for embedded use than bittorrent
<joepie91>
which has value, but is not groundbreaking decentralization research or anything
<infinisil>
It seems much more clean than bittorrent
<joepie91>
blockchains are an incredibly specific solution to an incredibly specific problem that almost nobody has (namely, the need for a trustless ledger being SO big that it's worth performance cost, operational cost, complexity and a bunch of other things) and that's currently being abused for a lot of shit it's absolutely not suited for
<infinisil>
Okay I have had a blockchain question recently and i bet you can answer it
<joepie91>
infinisil: well yes, that is likely because it's designed for embedded use and not part of a fixed type of filesharing application :)
<infinisil>
What does a blockchain provide over a consensus algorithms like Raft/Paxos?
<joepie91>
infinisil: I'm not super familiar with raft/paxos, but afaik they are meant for consensus building in a *trusted* system; ie. you trust each of the nodes to, at worst, behave wrongly unintentionally, but never with actively malicious intentions
<infinisil>
Ohh yeah that makes sense
<joepie91>
(or at least there is a single trusted node)
<joepie91>
infinisil: a blockchain is specifically about *trustless* consensus; there's not a single node that can be trusted with anything at all ever for any reason
<joepie91>
even if a node is actively malicious, it should be infeasible for it to affect the network integrity; that's the premise behind blockchains
<joepie91>
(through a combination of technical and economic constraints)
<infinisil>
something byzantine
<joepie91>
the problem with trustless anything is that 1) it's virtually always super expensive to implement, and 2) the solutions are almost always highly specific to a particular situation, data structure, etc.
<joepie91>
which is why you only want to use trustless consensus mechanisms, of any kind, if your thing actually needs to be trustless
<joepie91>
even in most decentralization usecases, you don't actually need trustless, you just need trust delegation, and now you end up at federated systems which are an order of magnitude easier and cheaper to build
<joepie91>
(see also: email, XMPP, ...)
<infinisil>
what is an example of those "most decentralization usecases"?
<joepie91>
email, for example :)
<infinisil>
oh right
<joepie91>
you don't want to rely on a single messaging service for the world
<joepie91>
thus, email, which is a federated system
<joepie91>
you delegate trust to a provider, optionally make your own provider, and interact with other providers who act on behalf of users
<infinisil>
DNS is one too, right?
<joepie91>
no, DNS is hierarchical
<joepie91>
ICANN sits at the top
<infinisil>
Oh right
<infinisil>
The root domain
<joepie91>
yep
<infinisil>
Okay is namecoin a valid usecase for a blockchain?
<infinisil>
I'd think os
<infinisil>
so
<joepie91>
infinisil: namecoin is a bit of a special case, because you have a chicken-and-egg problem
<joepie91>
infinisil: one of the requirements of an effective federated system is that you have an addressing scheme of some sort
<joepie91>
infinisil: but... namecoin *is* an addressing scheme
<joepie91>
or rather, an addressing system
<infinisil>
What do you need an addressing scheme for for a federated system?
<joepie91>
so if you want a naming/addressing system to work in a federated manner, you have to have an additional administrative layer for addressing the addressing requests
<joepie91>
... and now you have BGP
<joepie91>
BGP being the routing protocol of the internet
<infinisil>
Yeah I know of BGP
<joepie91>
[11:50] <infinisil> What do you need an addressing scheme for for a federated system?
<joepie91>
otherwise your node can't know where to delegate a message to
<joepie91>
in email, the addressing scheme is <user>@<provider>
<infinisil>
You mean the boostrap process of blockchain nodes?
<joepie91>
I'm not talking about blockchains here at all
<joepie91>
I'm talking about addressing schemes being required for federated systems
<joepie91>
so if the system you're trying to build is itself an addressing/naming system, it's difficult to do it in a federated manner
<joepie91>
without BGP-like peering hacks
<joepie91>
which is a potential argument for namecoin being totally trustless rather than trust-delegated (federated)
<joepie91>
hence a potential argument for it using a blockchain
<infinisil>
Hmm, so is there something wrong with namecoin? I'm failing to see the argument
<clefru>
infinisil: you are an ETH student?
<infinisil>
Ah
<infinisil>
clefru: Yeah
<joepie91>
infinisil: I'm not saying there's something wrong with namecoin :P I'm arguing why it might be justifiable to use a blockchain for namecoin
<infinisil>
joepie91: yeah got it now
<joepie91>
it's possible to do it without a blockchain, but then you need an extra administrative peering layer like for BGP
<joepie91>
(or... I think cjdns does that the same way, as BGP?)
<infinisil>
And then it won't be decentralized
<clefru>
infinisil: oh nice, I do live in Zürich. Come to ZRH Bitcoin meetups to discuss all about blockchains :)
<joepie91>
infinisil: oh, it'll be decentralized, it'll just be a pain to manage
<joepie91>
like, BGP is decentralized
<infinisil>
clefru: Haha, not sure about that, I have plenty of things to do and spend time on other than blockchains :P
<joepie91>
and we're still paying the cost for that decades later :)
<joepie91>
with random ASes just hijacking entire IP allocations
<infinisil>
clefru: But thanks for the invitation
<joepie91>
because people didn't realize that oh, maybe a federated system needs security properties too...
<joepie91>
(which is understandable to some degree in historical context, but that does not make it any less painful today)
<infinisil>
Alright I need to go, nice discussion joepie91!
<clefru>
speaking of blockchains, anybody interested in mimblewimble/grin here?
<clefru>
I painstakingly packaged it somewhat yesterday, my first rust experience
<makefu>
clefru: put it in an overlay and at some (hopefully not that far) point in the future NUR (nix user repositories) will be ready for indexing: https://github.com/nix-community/NUR
<lejonet>
joepie91: like that time when a chinese (I think it was, that or korean) hijacked all of level3s traffic? :P
<sphalerite>
hm so it looks like in fact there isn't really much active support for SPARC in any linux distros :(
<sphalerite>
also: why does the USB HID spec not provide for keyboards to tell the host about their layout?
<sorear>
i think because historically keyboards aren't supposed to care about layout
<sorear>
since they key arrangement is fixed and the key->letter mapping used to be a software problem
<sorear>
am I just imagining things or are interestingly-layouted ergonomic keyboards more of a thing now than when USB was new?
<samueldr>
even the 104-105 keys difference is sometimes only done (on cheap keyboards) through having contacts being unused under keys
<samueldr>
I have a cheap~ish keyboard which has unused, but working, contacts under the space key for the additional modifiers for japanese input
<coconnor>
I think they are definitely more of a thing
<gchristensen>
3d printing has made it easy to experiment
<coconnor>
and interfaces should take into consideration the physical layout. Definitely haven't seen an industry spec for specifying "layout" tho
<sphalerite>
sorear: but surely by the time an underlying protocol as complex as USB came around they would have thought to make things easier to configure
<sphalerite>
not even necessarily to have the keyboard report its full layout, that could be left up to the driver, but to just have some standard layouts which the keyboard can then report to the driver…
<gchristensen>
yes it is much easier to configure my keyboard via the host computer than the device -- everybody, circa origins of usb
<sphalerite>
I think apple's keyboards do something like this?