rodarmor

That's a good idea. There's already a `--glob` option, which allows selecting what to include with globs. It's the inverse of `.gitignore`, so `--glob foo` includes foo, and `--glob !foo` ignores foo.

I think that the glob library I'm using implements the same syntax as `.gitignore`, so it would be easy to add an `--ignore-file PATH` option.

I opened an issue to track this: https://github.com/casey/intermodal/issues/378

I just registered #intermodal on freenode. I'll also mention that in the readme.

I think those are fair points.

Personally, I have found Matrix to be extremely buggy, and much less usable than Discord. And, I now have an IRC setup that works for me using IRCCloud, but that took a while and I pay $5 per month for it.

Also, although Discord somewhat isolates one from older generations, IRC or Matrix somewhat isolates one from a different group, and I think it would be hard to argue that one was more important than the other. I've already gotten a bunch of early use, along with a lot of feedback, from users on Discord.

But, I do use IRC, so I should definitely consider having a link to #intermodal on Freenode in the readme. I sort of worry about fragmenting the chat, and having to check a lot of chat clients tho :/

It tries to ignore common junk files, and it can be configured to ignore things when invoking it with `--glob !PATTERN`, but there isn't anything like a `.gitignore` file at the moment.

Were you thinking of a `.gitignore` file that would be global? Like `~/.config/imdl/ignore`, or on a per-torrent basis?

I'd like to add a config in the future, and adding files to ignore to the config could be useful.

Do clients actually expose that functionality? I haven't seen those BEPs being used in the wild, so I'm very curious of features using those BEPs are actually available to users in existing clients.

I think the main benefit would be how much it would simplify software. Software that wants to do something useful with user-downloaded content doesn't have very good options.

To do more than just display a list of files, and maybe try to render a preview based on the file extension, software has to implement support for reading lots of different kinds of files and parsing lots of different kinds of metadata in those files. (MP3, MKV, PNG, JPG, OGG, etc).

And then, because the data contained in that metadata is only semi-structured, and varies between content types, it has to do a lot of error-prone heuristics to do anything useful with that metadata. Like, for example, figure out that these files are the tracks of an album, and this file is the cover art.

This is definitely possible! But it's very hard, and even then has a long tail of issues.

If a publisher or packager could add structured metadata with a constant format and filename to a release, then all the downstream software and services could mechanically consume that one source of metadata, which would simplify everything enormously.

Thank you!

A sort of no-setup BitTorrent-only proxy would be interesting, to avoid NAT issues.

I just downloaded the danbooru2019 metainfo files, and used `imdl torrent show` to view them, which worked. (Those are some big torrents!)

I don't support non-unicode filenames, which is pretty unfortunate. I have a hunch that it would be a little painful to add, and that time might be better spent on other features, but I could be convinced otherwise if there was a strong need!

I think that Iota is different here. Ethereum has a lot of issues, but it is not unfixably broken in any fundamental way. Iota is unfixably broken in multiple fundamental ways.

1. It's a DoS vector. Can you think of why?

2. Then by creating new outputs one could make the snapshot arbitrarily large, making it impossible to sync a single snapshot.

3. Why?

4. Why?

5. So you agree there's an unfixable DoS vector?

6. Why?

Why are they moot? Also, the team is arrogant, incompetent, and dismissive, and r/Iota is heavily moderated by them.

IOTA is traded on Bitfinex, which I think allows shorting, although I've never done it.

One thing to keep in mind though is that the market is not particularly rational, so even though I think IOTA is doomed in the long term, in the short term it could go up, because markets. So if you do decide to short, make sure to figure out what degree of leverage is important, and what your appetite for risk is.

The IOTA devs are deluded. Here's there justification:

"Creating a new cryptographic hash function is no trivial undertaking, even when it is being built on preexisting world class standards. “Don’t roll your own crypto” is a compulsory uttered mantra that serves as a good guiding principle for 99.9% of projects, but there are exceptions to the rule. When spearheading technology for a new paradigm this statement is no longer axiomatic. Progress must march on."

IOTA is trash for this and other reasons. You should short it. Issues:

1. Double spends are devastating and easy, since they permanently split the tangle.

2. With no transaction limit, syncing from the beginning of time will take forever.

3. With no transaction limit, keeping up with network traffic will be impossible. (Especially on IoT devices.

4a. Nobody is going to use power and die space on IoT devices for the PoW chip.

4b. Or, alternately, if, as they claim, the PoW chip will take very little die space and very little power, the network will be destroyed outright by non-IoT PoW chips spamming the network.

5. There is currently a coordinator which confirms transactions. It is not P2P. If they remove the coordinator, I could write code that destroys the network by issuing TiB of transactions per day, making it impossible to sync/keep up.

6. Mesh networks of the type that they envisage deploying IOTA on are not widely deployed, and it's not clear that they will ever be widely deployed.

7. Tip selection does not converge.

Since you can't store the private key needed to decrypt the files in ethereum, I can't think of how to do this.

All blockchain state is public, since it needs to be calculated by and verified by all nodes, so there's nowhere to stash a private key without revealing it.