LWN: Comments on "Ryabitsev: Patches carved into developer sigchains"

Ryabitsev: Patches carved into developer sigchains

flussence — Fri, 19 Jul 2019 21:09:52 +0000

I can't recall the last time I had to think in terms of raw SQL to get something done using Fossil. I can't say the same for blockchains and Git though. Perhaps those people who think they have too much brain to fit in the room are kidding themselves.

Ryabitsev: Patches carved into developer sigchains

bluss — Wed, 17 Jul 2019 18:50:31 +0000

It sounds awesome, but I was half expecting he was going to say it was written in nock and hoon.

(Maybe you know the reference to a well known but obscure project)

Ryabitsev: Patches carved into developer sigchains

Wol — Wed, 17 Jul 2019 10:26:42 +0000

> Now to be fair the SQL language does hide solid computer science behind a management-speak appearance...

You know what I think of First Normal Form databases ...

As soon as you break the Relational rule that you can only talk to databases in two dimensions then things become better, but any database that only works in rows and columns is "broken by design".

(And yes, relational theory is brilliant at ANALYSING your data structure - it really is - but don't use it to build the database itself!)

Cheers,
Wol

Ryabitsev: Patches carved into developer sigchains

lkundrak — Sat, 13 Jul 2019 19:45:23 +0000

> I don't think there's any kernel maintainer left who doesn't use git.

Andrew Morton

Ryabitsev: Patches carved into developer sigchains

smurf — Sat, 13 Jul 2019 14:34:52 +0000

> The fundamental premise of the Decent fantasy universe is that there exists some app that is sufficiently popular that you can expect every open source developer to have a current version of it on their phone

So? When Linus invented git, git was that fantasy tool, and initially quite a few maintainers declared their continued (*) unwillingness to switch away from a purely-email+patch-based workflow.

(*) because Bitkeeper. Which incidentally is now Apache licensed … and has seen a whooping FOUR changes during the last year …

Today? I don't think there's any kernel maintainer left who doesn't use git. The problem is that git is necessary but not sufficient for a huge multi-maintainer repository like the kernel, the existing tools (email-based patch distribution and review and bug tracking and whatnot) continue to not scale, … so we need a new tool.

Ideally, a tool that's as cool for distributed collaboration as git is for distributed code sharing will be adopted widely enough that the "everybody has it on their phone" problem is a non-issue because, well, everybody *does* have it on their phone.

Pipe dream? perhaps. But git started as some basic concepts and a rather basic tool, too – and now look at the infrastructure around it. The lesson is that, yes there needs to be an initial need for the tool – but much more importantly, the concepts behind the tool must be sound.

Sigchains are one of these; for a real collaboration tool they, or something resembling them, are necessary but not sufficient.

Ryabitsev: Patches carved into developer sigchains

marcH — Sat, 13 Jul 2019 03:21:56 +0000

> For all the years that we've been doing Fossil, folks have been throwing shade on us and saying things like "Why don't you use Git like everybody else because Git is Awesome!". I have several answers to that question,...

There is a very easy answer to this sort of questions when you feel lazy: ask back whether the people who made git were using Subversion just like everyone else

Ryabitsev: Patches carved into developer sigchains

marcH — Fri, 12 Jul 2019 17:08:08 +0000

> How do you imagine this works now?

I don't, that's the point you keep missing.

> They're preinstalled

Ryabitsev: Patches carved into developer sigchains

zblaxell — Fri, 12 Jul 2019 17:02:59 +0000

> I don't need an app to send pictures or contacts to someone else's phone over bluetooth

How do you imagine this works now? There's an app for that, probably several (one for pictures, one for contacts, one for SMS messages, a separate one for every other Bluetooth profile you want to use). They're preinstalled (or baked into the "system services" module for the phone OS) but they don't require privileges that aren't available to other developers. You probably can't _remove_ any of them if they turn out to be security swiss cheese because your vendor didn't want to fork over a pile of cash to recertify their 0day-filled Bluetooth stack.

You can download support for any protocol you like in 20 seconds from your phone vendor's app store. You probably do have to do that before you get to the conference, though.

> and don't want to install one. That's the use case in the parent article and the one I'm referring to.

Maybe in some alternate reality Google will put Decent on every Android phone. Hahaha I'm kidding, in the Decent fantasy universe, Decent is the thing open-source people are using instead of the equivalent Google tool or service.

The fundamental premise of the Decent fantasy universe is that there exists some app that is sufficiently popular that you can expect every open source developer to have a current version of it on their phone, ready to use for convenient ad-hoc project distribution. If you reject that, you reject the entire story in the OP. (Maybe you do reject the entire OP, but in that case the choice of Bluetooth vs WiFi as bit-level transport would be irrelevant.)

> All the WiFi infrastructure you just described indirectly is great news (and the technical comparisons are very interesting, thanks) but unfortunately not enough for people to start using WiFi to merely send something to someone else's phone until it's just one simple, direct access item in the "share" menu. And again even bluetooth comes a bit short there, depends on what is a "socially tolerable amount of time" for the other person.

There's no way that's happening without an app on the phone to orchestrate. The good (?) news is that any random app on the phone can add its own "share" menu entries.

Ryabitsev: Patches carved into developer sigchains

marcH — Fri, 12 Jul 2019 16:24:02 +0000

> I have an app on my Android phone [...] I have another app [...]

I don't need an app to send pictures or contacts to someone else's phone over bluetooth and don't want to install one. That's the use case in the parent article and the one I'm referring to.

All the WiFi infrastructure you just described indirectly is great news (and the technical comparisons are very interesting, thanks) but unfortunately not enough for people to start using WiFi to merely send something to someone else's phone until it's just one simple, direct access item in the "share" menu. And again even bluetooth comes a bit short there, depends on what is a "socially tolerable amount of time" for the other person.

> I think you need to visit a consumer electronics store.

No thanks, I've educated too many sales people already ;-)

Ryabitsev: Patches carved into developer sigchains

zblaxell — Fri, 12 Jul 2019 15:34:27 +0000

> You do have the Decent app on your phone, so you scan the QR code

That's the pointer...

> and wait until your phone shows you the usual ?replica complete? checkmark [...]
> the data went straight from their phone to yours without needing to hit any other systems on the net.

...that's the data.

> Not only I never saw anyone using this, I don't think I ever heard of it...

I think you need to visit a consumer electronics store.

All-in-one printers in the last few years support a mode where the printer becomes a WiFi hotspot, and phones can send photos to them. There might even be cross-vendor standardization now (but in case there's not, there's always an Android app that matches the printer).

People watch TV using their phone and TV stick devices using Allcast. Ignore the media-encryption stuff, the basic transport and discovery protocol is all that's required for Decent.

I have an app on my Android phone that can configure my 3D printer's WiFi over WiFi, using some bespoke hostap discovery protocol and a pairing mode. I have another app that just sets up a local WiFi hotspot without the upstream data link (so it works even if tethering is disabled on the phone), using half of the usual Android hotspot setup and routing APIs. A QR code would provide more than sufficient information to organize two devices to use a hotspot running on one of them.

> Also, if the level of WiFi noise makes Access Point performance horrible, then I'm a bit sceptical about the ability of these wonderful thing to automagically configure themselves to jump to the frequencies that... the venue forgot to use by chance?

The venue will use one channel group in each area (or one 2.4GHz and one 5GHz channel group); otherwise, their own access points' beacon frames will interfere with each other's data transmissions. Decent can pick any of the other frequencies and/or use a narrower channel band, and still get megabits over short noisy distances.

WiFi has brute force transmission power, battle-tested noise discrimination, and access to 5GHz frequencies, that Bluetooth does not. Two attendees at a conference can transfer a file over a distance of a few feet (granted, they degrade the conference's WiFi further while they do so, but hopefully they don't do it for long...). WiFi still works when you have hundreds of (distant) neighbors. Bluetooth not so much--the workable distances are measured in inches, and you maybe get a few kilobits of usable bandwidth. Even NFC would be better than Bluetooth.

Ryabitsev: Patches carved into developer sigchains

marcH — Fri, 12 Jul 2019 05:57:25 +0000

https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-gi...
> The difference is that Git stores its objects as individual files in the ".git" folder or compressed into bespoke "pack-files", whereas Fossil stores its objects in a relational (SQLite) database file

So, Linus Torvalds, a filesystem person, stored git objects in files and "pack-files". To solve the same problem, the SQLite people use - surprise, surprise - a relational database.

Curious what is the background of the creators of SBB?

Ryabitsev: Patches carved into developer sigchains

marcH — Fri, 12 Jul 2019 05:49:59 +0000

> Modern smartphones have ad-hoc WiFi and media-distribution protocols that can send gigabytes of data in minutes. It's supported and working in production consumer devices now

Not only I never saw anyone using this, I don't think I ever heard of it... There might be a user interface issue? Not like peer-to-peer bluetooth is super user-friendly either, but at least "some" people find it usable. What are these magical, "zeroconf" WiFi-based protocols and is there a good HOWTO somewhere?

Also, if the level of WiFi noise makes Access Point performance horrible, then I'm a bit sceptical about the ability of these wonderful thing to automagically configure themselves to jump to the frequencies that... the venue forgot to use by chance?

Anyway I don't think the original blog ever suggested to use Bluetooth to actually transfer the data but just pointer(s) to it:

> You don't even know if your phones used NFC, Bluetooth, or WiFi for this *little chat* [emphasis mine] You open the Decent app on your phone and it shows a short ID code

Ryabitsev: Patches carved into developer sigchains

marcH — Fri, 12 Jul 2019 02:31:57 +0000

> It's really strange that Fossil isn't much more famous.

The moment you say or write "SQL", the vast majority of people with a brain have left the room instantly. The entire room if it was a room of Linux engineers. Then it's too late no matter how smart was what you had to say next.

You can get a smaller but still measurable effect if you say "database". Why do you think some engineers call a task/bug tracker a tool "for managers"?

Now to be fair the SQL language does hide solid computer science behind a management-speak appearance...

Ryabitsev: Patches carved into developer sigchains

epa — Thu, 11 Jul 2019 11:10:32 +0000

But as I understand it, the format of SSB data is not defined anywhere, beyond calling it "JSON". It is defined in an ad-hoc way as whatever the current version of some particular JSON library produces. That even means a backwards-compatible upgrade to the library (backwards compatible in the JSON world, since what it outputs is still correct JSON and parses to the same thing) could break SSB.

Perhaps I'm wrong and as you say, it is carefully defined as "SSB format" which just happens to be a superset of JSON. If so, there is a lack of tool support for this format in languages other than Javascript.

Ryabitsev: Patches carved into developer sigchains

zblaxell — Wed, 10 Jul 2019 15:10:17 +0000

> if one usecase is to exchange updates over Bluetooth or similar protocols, you want to keep the overhead small

In the Decent fantasy universe--which includes a "two strangers share something the size of a Usenet newsgroup between smartphones in a socially tolerable amount of time" scenario--the one thing that breaks my suspension of disbelief is the absurd notion that Bluetooth is a candidate protocol to transfer a project repo between two smartphones. Modern smartphones have ad-hoc WiFi and media-distribution protocols that can send gigabytes of data in minutes. It's supported and working in production consumer devices now. In any conference environment that is too electromagnetically noisy for a protocol based on WiFi to work (think 100 people in a single room, all using WiFi at once), Bluetooth has no hope.

A sane transport implementation is probably going to pipe the data through zstd, and that's going to eliminate most of the encoding overhead no matter what encoding is used underneath. For long sequences of short messages, the biggest thing in the bitstream is likely to be the signature blobs. The only way to reduce the signature overhead is to have fewer signature blobs or make them weaker.

Ryabitsev: Patches carved into developer sigchains

zblaxell — Wed, 10 Jul 2019 14:12:41 +0000

Indeed, nobody is debugging the contents of a Git pack file with 'vi'.

The standard solution for this is a strict parser (to reject badly formatted messages) combined with a separate pretty-printer (for humans to debug). Compare the output of 'git cat-file tree HEAD:' with 'git cat-file -p HEAD:'.

Ryabitsev: Patches carved into developer sigchains

zblaxell — Wed, 10 Jul 2019 14:09:51 +0000

> You either depend on the quirks of a particular encoder implementation (which seems to be what happened here), or you define a canonical form and make sure all JSON is in that form before you hash it.

Both of those are the same thing. You need a "SSB encoder" not a "JSON encoder". Maybe SSB happens to look a lot like JSON, and maybe there are historical reasons why one existing JSON encoder happens to also work as a SSB encoder (for now), but they are not the same thing.

For security reasons you want a single canonical encoding; otherwise, you end up vulnerable to padding oracles, hash collision attacks, covert channels, etc. That requirement means you can't just say "any valid JSON goes" and accept input from arbitrary encoders. Encoding might as well be provided by a protocol-specific encoding library.

Ryabitsev: Patches carved into developer sigchains

zblaxell — Wed, 10 Jul 2019 12:50:25 +0000

> Why don't you use Git like everybody else because Git is Awesome!

I used to think that way...until I did a semi-serious attempt to convert the Fossil and SQLite source histories into a Git repo--not any of the other data in the archive, just the parts Git can understand. The resulting Git repo was significantly larger than Fossil's version even after trying the usual Git optimizations, and maybe a bit slower too (though that's just subjective feel, I didn't bother with performance benchmarks because Git is good enough for now, and I couldn't solve the size problem).

It's really strange that Fossil isn't much more famous. Anyone who wants to design a new distributed developer's tool should be able to intelligently answer questions about why they did something different from Fossil.

Ryabitsev: Patches carved into developer sigchains

edomaur — Wed, 10 Jul 2019 11:39:16 +0000

Well... SSB doesn't seems to have a really high entrance barrier...

Ryabitsev: Patches carved into developer sigchains

flussence — Wed, 10 Jul 2019 07:54:39 +0000

It seems a bit pointless to argue for half of this system using a human-readable plumbing data format when the other half (Git) doesn't.

Ryabitsev: Patches carved into developer sigchains

samlh — Wed, 10 Jul 2019 04:40:41 +0000

This is a pretty good explanation: https://blog.ffwll.ch/2017/08/github-why-cant-host-the-ke...

Ryabitsev: Patches carved into developer sigchains

jkblee — Tue, 09 Jul 2019 19:46:22 +0000

This sounds like a NIH syndrome to me. Why wasting time to reinvent what works already for majority? If email is not an option, what other suggestion do you have? Right now the kernel bugzilla is a catastrophe as well that no one actually checks and issue workflow via email does not really scale well either. What would be the alternative with a low entrance barrier for majority of developers?

Ryabitsev: Patches carved into developer sigchains

drh — Tue, 09 Jul 2019 18:33:37 +0000

Fossil is ... not an acceptable solution for the Linux Kernel due to needing to force everyone to switch away from git.

This fact is understood and anticipated. I wasn't advocating that you switch, only that you perhaps look over our experience of the past 11 years, perhaps steal some ideas and/or some code, and maybe learn from our mistakes.

For all the years that we've been doing Fossil, folks have been throwing shade on us and saying things like "Why don't you use Git like everybody else because Git is Awesome!". I have several answers to that question, one of which is the argument that you (I'm assuming that mricon==Konstantin, correct me if I'm wrong) very eloquently made in your recent blog post, the part about "it's time for us to come up with a solution that would offer decentralized, self-archiving, fully attestable, 'cradle-to-grave' development platform that covers all aspects of project development and not just the code". That's one of the big reasons that SQLite has been using Fossil instead of Git all along. And all that time, I've struggled mightily to get people to understand it, seemingly without making any headway. So when somebody at kernel.org says essentially what I've been trying to say for a decade, I'm like "Wow!" And then I think maybe my years of experience in this area can help guide your design.

But perhaps this comment thread is straying too far off topic? Maybe follow-up on the Fossil Forum Thread or direct email to drh at sqlite.org, if you choose.

Ryabitsev: Patches carved into developer sigchains

mricon — Tue, 09 Jul 2019 18:08:47 +0000

I admit that I haven't looked at fossil in very deep detail, mostly because it necessarily requires migration away from git -- which is a non-starter for the kernel community. Therefore, I may be mistaken about some important aspects of how it works.

I see that servers may set up sync relationships between each-other, but this must be done on the basis of trust external to the platform itself -- if I run a fossil replica, you won't be aware of my work unless I ask you to set up a sync with me. There are significant downsides to this scheme as opposed to the ad-hoc replication framework of SSB, mainly because the fabric is not self-healing -- if a malicious actor targets all known replicas, they can effectively shut down all collaboration on the project unless members of the community use some third-party channel to coordinate new replicas. With SSB, even if major replication pubs are targeted, peer-to-peer replication still works and organizing new pubs doesn't require using an external communication and coordination platform.

If Fossil is working for some people, then that's great, but it's not an acceptable solution for the Linux Kernel due to needing to force everyone to switch away from git.

Ryabitsev: Patches carved into developer sigchains

Cyberax — Tue, 09 Jul 2019 17:29:27 +0000

> Canonical JSON is anything but "easy to debug" when you're in the realm of nontrivial messages. You don't count curly parentheses to see which level an element is at, you pretty-print the thing, at which point you already parsed it and the original encoding no longer matters.
The thing is, I can output the raw json or even read it from inside a debugger. Then I can trivially pretty-print it. If it's a web service, I can usually log it using various debug options.

With a binary format there's no such easy way to do it.

Ryabitsev: Patches carved into developer sigchains

Cyberax — Tue, 09 Jul 2019 17:22:51 +0000

Github is a proprietary service, with an issue workflow that won't really scale to the level of Linux kernel.

Ryabitsev: Patches carved into developer sigchains

drh — Tue, 09 Jul 2019 17:18:18 +0000

Fossil is not decentralized in the same sense that Git is not decentralized. You can clone it and fork it, but you require a canonical location of the repository for everyone to effectively collaborate...

False. Fossil will work completely decentralized, with no canonical server. Individual developers can push and pull content (code, wiki, tickets, forum posts, etc.) among themselves on an ad hoc basis. In the limit, everybody will end up with the same content.

Having a canonical server certainly makes collaboration a great deal simpler, since you don't have to rendezvous with some other community member to share your work, and since the canonical server will usually have most, if not all, of the latest changes so you don't have to pester other developers for rendezvous opportunities in order to pick up the latest changes. Having a server is very convenient. But it is not required.

The objective of Fossil is not to eliminate the central server or the benevolent dictator, but rather to reduce the number of external dependencies on the project so that:

it can be more easily cloned and forked should the dictator abdicate or go rogue,
the project can easily move to a new host as technologies evolve and as hosting companies go in and out of business, and
so that the project is less easily censored or deplatformed by a hosting provider or government that does not approve of its direction.

Ryabitsev: Patches carved into developer sigchains

pbonzini — Tue, 09 Jul 2019 17:08:00 +0000

That was DejaNews!

Ryabitsev: Patches carved into developer sigchains

idrys — Tue, 09 Jul 2019 16:54:32 +0000

> If other large communities which build infrastructure that a lot of people rely on such as Kubernetes are on Github why can't the Linux kernel be?

Ugh, please no centralized infrastructure; be it GitHub, GitLab, or whatever.

Ryabitsev: Patches carved into developer sigchains

mricon — Tue, 09 Jul 2019 16:30:40 +0000

Fossil is not decentralized in the same sense that Git is not decentralized. You can clone it and fork it, but you require a canonical location of the repository for everyone to effectively collaborate (e.g. same as Linus has a canonical repository -- if it goes away, he or his replacement must designate what the new canonical repository is, and everyone must agree with that decision). At best, Fossil allows you to have read-only mirrors that you can promote in case the main server becomes unavailable, but no true decentralization -- Bob and Alice can't use a replica in Australia, while Charlie and Della are using a replica in Canada.

So, yes, Fossil is self-archiving, but you still have a single point of trust and authority with no built-in attestation. It still wants to set up cathedrals in the world that's excedingly good at targeting and taking out (or taking over) cathedrals.

Ryabitsev: Patches carved into developer sigchains

drh — Tue, 09 Jul 2019 15:59:17 +0000

Fossil (https://fossil-scm.org/) is a decentralized, self-archiving, fully attestable, 'cradle-to-grave' development platform that covers all aspects of project development. It was written to support SQLite development and has been in use on that project (and many others) for over a decade. The self-contained stand-alone Fossil executable is a GitHub-in-a-box that installs using a 2-line CGI script (as well as other options) and supports all aspects of project management. Fossil is well supported and has an active and enthusiastic user community.

Probably Konstantin wants something Git-based. Fine. But he (and others) might at least give Fossil a look in order to steal ideas that have been refined and tested on that system over the past 10 years.

Ryabitsev: Patches carved into developer sigchains

jkblee — Tue, 09 Jul 2019 15:14:38 +0000

If the idea is to remove issue of email workflow in the long term, then kernel devs needs to change their workflow one way or another. Github is battle-tested with large scale projects already and has a lower entrance barrier as well for new developers (yes, new people and workflow matters, it's both and not just the latter). Why reinvent the wheel? ;)

Ryabitsev: Patches carved into developer sigchains

Wol — Tue, 09 Jul 2019 14:46:07 +0000

Because somebody - can't remember who - took over responsibility for archiving news and this became pretty much a "single point of failure". Then Google took that over and turned it into Google Groups.

Combine that with the volume of spam, and I remember Demon (who had one of the biggest news feeds) had major problems scaling to cope with it. It just grew too big and imploded :-(

Cheers,
Wol

Ryabitsev: Patches carved into developer sigchains

mathstuf — Tue, 09 Jul 2019 14:39:27 +0000

It's not the number of people that matter, but the workflow. Github just doesn't support the workflow that kernel developers are comfortable with and use day-to-day.

Ryabitsev: Patches carved into developer sigchains

jkblee — Tue, 09 Jul 2019 14:37:06 +0000

If other large communities which build infrastructure that a lot of people rely on such as Kubernetes are on Github why can't the Linux kernel be?

Ryabitsev: Patches carved into developer sigchains

mricon — Tue, 09 Jul 2019 14:23:33 +0000

Yes, you can reference the message-id of the bug you want to link to. See: https://ssbc.github.io/docs/ssb/linking.html

Ryabitsev: Patches carved into developer sigchains

welinder — Tue, 09 Jul 2019 13:56:37 +0000

Re-tooling Linus is going to be the problem, not re-tooling patch handling. Email has served him well for handling patches.

Ryabitsev: Patches carved into developer sigchains

mjthayer — Tue, 09 Jul 2019 13:40:47 +0000

Would cross-referencing bugs from other bugs work too?

Ryabitsev: Patches carved into developer sigchains

mricon — Tue, 09 Jul 2019 12:30:07 +0000

SSB records are structured data, so adding a specific record type ("type": "issue-report") is easy. The harder part is to agree what the standard for that should be, but looking at projects like git-bug and git-appraise should help figure out what kind of records should go into an issue-report.

Ryabitsev: Patches carved into developer sigchains

mricon — Tue, 09 Jul 2019 12:23:43 +0000

Smaller than you'd think. For example, 20 years of vger.kernel.org archives is currently around 20GB. Clients lazy-load the chains as they cross-index the conversations, so someone replicating the entire archive would be able to participate without needing to wait for the entire thing to replicate.