@nev @ada I had a very similar problem when I had an Acer Aspire One.

@Wolf480pl @nev @ada Oh, the memories.

@Wolf480pl @ada before this my computer was an Asus 1001P, loved it to bits but the poor thing just couldn't keep up with the times

@Wolf480pl @ada @quad There is always MUTT as an option, no?

@profoundlynerdy @ada @quad yeah, it is for email, assuming no important email comes as HTML-only.
The IM landscape tho... it's a mess of app-specific JSONs over http, and clients written in heavy JS frameworks.
IRC is still there, but many people refuse to use it due to lacking features, and XMPP is trying to catch up but it too doesn't have all those features yet.

@Wolf480pl @ada @quad Yeah. IRC is wonderful. It "just works" and can be run over an encrypted tunnel just fine.

XMPP has more features than IRC, but it isn't snap chat.

Mastodon is the new Twitter.
Twitter is the new Finger
Snapchat is the new text message... is the new AIM/ICQ... is the new IRC.

@profoundlynerdy @ada @quad
Slack/Discord is the new IRC.
Facebook Messenger/Telegram/WhatsApp is the new AIM/ICQ

@Wolf480pl

configuring mutt to use w3m to view HTML parts in email doesn't solve everything, but it handles a lot of it.

I'd take an HTML email any day over some email announcements I get where details are only in some image part.

@Wolf480pl @profoundlynerdy @ada @quad None of the features folks claim #IRC lacks are useful or desirable. Read receipts are a mistake in any protocol that contains them.

@duck57 @profoundlynerdy @ada @quad
The my friends usually miss are:
- message history
- inline code snippets
- inline images

@Wolf480pl @profoundlynerdy @ada @quad In-line code is a useful case (I’m used to inline images being handled by the client expanding all the links to images).

I like that IRC isn’t logged by default, but sometimes it would be nice to have more context than just ZNC’s scrollback buffer

@duck57 @profoundlynerdy @ada @quad
>ZNC's scrollback buffer

Well, imagine you have friends that don't have ZNC. Or a server to put ZNC on. They join a channel, and have no idea what happened when they were away.

Also, people tend to use Slack, etc. for non-entirely-ephemeral communications.

@Wolf480pl @quad @ada @profoundlynerdy @duck57 been trying to fix that all on my own here https://gist.github.com/SoniEx2/441dd24964c7fb3dc13d124db20914a0

@SoniEx2 @duck57 @profoundlynerdy @ada @quad
I started reading the spec, but nowhere did it say what it its purpose, and it seemed useless so I didn't finish reading it.
It doesn't seem to have anything in common with history retrival. What specific problem is it trying to solve? What's wrong with message-ids?
Also, how did #ircv3 channel like it?

@Wolf480pl @quad @ada @profoundlynerdy @duck57 IRCv3 hates everything they don't come up with themselves.

anyway, this provides a mechanism for distributed logging. there still needs to be a different mechanism for log syncing, but this provides the logs themselves.

@duck57 @profoundlynerdy @ada @quad @Wolf480pl (you wouldn't know what it does unless you're a crypto expert tho, I guess. sorry for not making that obvious. I don't make that obvious because IRCv3 just brings unfounded privacy complaints if you mention anything useful to them.)

@Wolf480pl @quad @ada @profoundlynerdy @duck57 in other words no I'm not gonna submit this to IRCv3.

if you want this to be an official IRCv3 extension, feel free to submit it. also prepare to be laughed at and ridiculed. I speak from experience.

@SoniEx2
I'm not sure what you mean by expert, but I'd be surprised it required expertise at the level of Schneier or DJB. I've read some cryptographic papers and had no problem understanding them.

So, can you please say what it is that you're trying to do, in big picture?

@Wolf480pl it's literally git for IRC.

every IRC message automatically becomes a git-like commit, and everyone currently online gets access to that commit.

if you have the current commit, you can ask other peers for previous commits, because the current commit also contains the cryptographic hash of the previous commit (and so on).

by doing it this way, we completely avoid issues with the GDPR and stuff.

@Wolf480pl the key term is "cryptographic hash" - you can't fake those. (well, you can, but that's like, hash collisions. good luck making those.)

@SoniEx2 I KNOW what a cryptographic hash is. And how SHA3 which you mentioned in the spec tries to be a cryptographic hash.

@Wolf480pl there are some improvements that can be done, like birthday attack resistance. (currently, there is none.)

@SoniEx2
oh man, where do I start...
- don't try to put anything P2P in IRC, that's scope creep. If you want P2P, make it P2P from start. P2P on top of a centralized IRC server has the drawbacks of both approaches, and benefits of none of them.
- I don't think designing technical standards around laws is a good idea. Laws will change, but network protocols will stay the same.
- it'd be a nightmare to implement, every irc client and server would need to implement a modified version of git...

@Wolf480pl the server does minimal work. always.

IRC servers shouldn't need tons of storage space.

IRC server should be ephemeral, except for metadata.

I keep that with this extension.

The laws are not something I designed this around, actually. I've had the idea long before any of the laws. I only mention it as a pro because it works regardless of the laws.

Also p2p on top of centralized is fine. We do it all the time. It's called DNS. See: mastodon itself.

@Wolf480pl If you're gonna complain about p2p/decentralized on top of centralized then you should stop using mastodon.

@SoniEx2
Mastodon is not P2P. It's federated.
If your server is offline, other servers won't store your profile or messages for you and let other servers retrieve them. You can't run a mastodon instance on a laptop that you turn off when you go to sleep.

@SoniEx2
ok, now that I know what it is that you're trying to do, I started reading the spec again, and it suddenly started making more sense. Still, I don't think it'll work well.

- you're adding 150% overhead
- are you sure the order of messages is always the same on all servers in a network?
- fetching history from other clients (which you didn't describe in the spec) won't work if no 2 people are online at the same time

@SoniEx2 consider the typical slack-like usecase: a team of 6 people, one goes online, asks a question, goes offline (gotta conserve battery), comes back 6 hours later, expects to see all replies that happened within those 6 hours. Who's gonna give that person the logs, if noone else is online at the moment?

@Wolf480pl don't mind the overhead, it's really not that big. it's nowhere near as big as sending the whole chat history when the user connects, and it keeps the complexity low on the server.

the order of messages is not always the same, nor does it have to be!

yes, if the channel is literally dead, it won't work. it relies on at least one user having a bouncer.

@Wolf480pl basically, it relies on IRC staying mostly as-is. I don't see that as a problem, but rather I see it as a feature, because ppl don't need to adapt to the new features. this can be used to drive adoption!

@Wolf480pl if the server wants to cache and replay some messages, it is free to do so. the extension is compatible with that.

@SoniEx2 if one user has a bouncer, then the whole team could just use that bouncer. Or, FWIW, use a partyline channel on that bouncer, and ditch the IRC network altogether.

With proper log replay, every message is sent exactly once to every user. With your solution, it'll hopefully also be sent exactly once to every user, but every message will be 150% bigger.

@Wolf480pl so what? these logs last forever! (as long as the hash function isn't broken) and they're self-healing/self-repairing.

@SoniEx2
Why do you even need the hash?
You could just obtain the logs the same way you'd obtain them with your solution, except without the hash, and it'd be more efficient.

@Wolf480pl well, this is a proof of concept

@Wolf480pl @ada @quad
The ploblem is also that more and more "native" apps, or so called, use electron.

@danyspin97 @ada @quad
Yes, that is a large part of the problem.
In case I didn't make it clear enough in my previous post, I count them as web apps, not as native apps.

@Wolf480pl @quad @ada But even it's in Qt, you do know QML and its crappy JavaScript, right? It's virtually no difference between these things nowadays, nowhere to escape.