IRCv3
ircv3.net
ircv3.net
It had a UI I prefer over anything since - compact, comparatively unobtrusive, information-dense, and fast. I could port my full chat history around with me between machines, and also search it reliably (no vanishing scrolling or lazy-loading handicaps). And it was handy you could advertise different presence states to different people/groups.
I still use IRC to this day, just the client and the OS are different.
Winamp hasn't aged so well, sadly.
Everything wants to make a "universal media library manager". Jesus, doesn't anybody just want to name their MP3 correctly and then use file management, and then have an audio player that just plays audio?
IIRC, the last time I used Audacious, the default interface was a loosely-inspired-by-itunes kinda UI, but tweaking the right knobs in the configuration screens could get it to a Winamp-like UI (or at least XMMS-like)
https://en.wikipedia.org/wiki/Audacious_(software) confirms a lot of my recollection.
Audacious... eh. Setting aside the bad default interface, my experience with that is the same as with most media players. The developers decided how your music should be organized, and they're going to do that for you whether you like it or not.
Edit: Hmm. Looking into it more, I don't think Audacious was changing my media library. I've no idea what it was that was doing it now, I just remember fighting with something managing my library until I stopped using Audacious.
As an early fan of Winamp, what I have found is that most people do not want the Winamp experience these day. The problem with Winamp is it came with no music, only a JJ McKay promo.
There are many players that seek to emulate the Winamp experience but much of the audience for something like that have moved on to Spotify. Today's audiences want a fully curated experience from their "Player", which Winamp was never designed to do.
That's not outsourcing curation. That's basically cloud storage + file sharing.
no because sometimes I care about artist, sometimes about title, sometimes about year of release, album name, etc. Using proper metadata is important. I almost never look at a filename unless I'm moving data from one machine to another.
In an era of indexing and lightning-fast search of documents, there's little reason to care about filenames.
Meanwhile today Teams seems to think that it needs a whole screen dedicated to itself… a place that I get nothing done.
In other words, designed by IT guys. And a reason (among many others) normies would never get on board. Not saying I disagree personally.
Nitro, Shop, and Quests. What are these even?
Even their changelog page is wtf (https://discord.com/tags/changelog)
Shop is where you can buy additional customizations.
Quests get you exclusive unlocks for various games.
Shop is where they sell customization stuff.
Quests let you earn currency you can use to buy customization stuff or nitro instead of real money.
I don't think there's a significantly better way to do whatever they are doing, and I don't see anything particularly objectionable about any of it.
We're you on IRC? Much more information dense.
Maybe I may officially old now, but I recall I could converse on IRC, not full screen, on a 800x600 15" monitor. Yes I know today we have tons of pictures and emojis and so we obviously need a bit more room. But common. Even slack takes slightly less room that discord for the same amount of information.
And yes, I enabled compact mode.
I cannot believe this stupid app is so popular when you can't even monitor multiple servers at once! When every brother and their mother has a discord server but I can only look at one channel on one server at a time??
However I like that I can see all the channel with unread messages at once, and can switch between them quickly. On Discord if I'm chatting in three channels spread across two servers then switching takes two clicks.
It's just yahoo groups that requires your phone number.
They're there of course because some 'normie' thing of theres inevitably requires the sign-up of a discord for bonus game skins or some other such stupid shit, but the fact remains that they're clueless.
much like the average Outlook user, they're there because they were dragged into it by another element in their life (their job) and they really have no background or clue on how to use the piece of software, they just know they need to pretend and cite experience on the CV for a job.
My 90s and early 00s social circle was AIM, Yahoo Games, and Neopets.
Once it did my local social circle used it. Gaming stuff stayed on IRC and ICQ.
AIM was filled with script kiddies using spam to "hack" people's computers. It just crashed the app when they spammed you.
Then stuff like trillium came out which meant you didn't have to use AIM's awful client.
Surely we can agree that no one's experience is universal, and both regional and subcultural differences are likely to have materially shaped our views of the various chat services in the '90s and early '00s...?
Surely we all recognize that our own experience is not The Default Everyone Should Understand?
AIM and ICQ were the big ones back in the day, nothing ever was as big as that.
ICQ was released 1996; Pidgin (as GAIM) was November 1998; Jabber was released in 1999. Those were good times.
I suspect part of that is because not everyone had broadband. I was still on dialup years after broadband ISPs were widely available.
Anyway, ICQ was not some elite hacker thing. Anyone with enough reading comprehension to tell milk and orange juice apart from reading a label could operate it just fine.
>ICQ was not some elite hacker thing
Sure, exactly IRC was that hacker thing.
Then MSN Messenger displaced it (at least in Spain) and it didn't have even 10% of ICQ's functionality.
I’ve been checking your client for a while and it looks awesome, thanks for the reminder, finally after 30+ years I think I really got tired and left IRC for good but I’ll download and give it a go later today.
ಠ_ಠ
I obviously write a lot of code in Go but as a language it's also a really nice pairing with the IRC protocol. The way you write abstractions and tests just lends itself so well to writing desktop applications. On the other hand, writing UIs in Go (which I've tried in a multitude of ways) is just a really poor fit because asking Go to emulate Elm architecture is very clunky.
From my perspective, UIs are side effect driven code and demand a language that can fit that paradigm not just well, but great. Anything else I would or could have chosen would've required way more CGO dependencies than I have (of which I only have 1 atm) and would have read worse when I tried to hook it into Go.
Conversely, Wails' bridge to Typescript and React is very simple to use, reliable, and keeps up with the performance and consistency demands on an IRC client. Tailwind is also just very good at making compatible CSS; I was inspired by the use of QT in modern car infotainment systems in my selection of a component-based CSS approach.
Lastly, the whole thing is compiled into the binary that you download and makes no external calls on its own. It's all built on top of the OS WebView rather than a third-party browser the way, say, Electron is.
Yeah, I think that's fair. I don't think about resource utilization in a vacuum: native apps require I develop three different apps and likely have a lot of CGO dependencies. With Wails and the OS WebView the same client you're used to using on MacOS should work the same or similarly on Linux and Windows within reason. They should also all maintain similar resource utilization profiles. That's why I said it's limited in its footprint, I'm not here to compete with native library performance and native library performance isn't trying to compete with my ability to cross-compile.
Process PID Avg CPU Footprint (MiB)
------------------------------ ------ --------- ---------------
Cascade 45314 0.46% 73.0
WebKit WebContent 45349 0.50% 392.9
WebKit GPU 45347 <0.01% 26.1
WebKit Networking 45348 0.02% 6.5
Nick completer plugin 45344 <0.01% 2.8
Nickname colors plugin 45345 <0.01% 9.7
ThemeWidget service 41353 <0.01% 10.1
SafariPlatformSupport helper 41355 <0.01% 13.1
------------------------------ ------ --------- ---------------
Total 1.00% 534.2
I'm currently connected to four networks for 6 days and 18 hours. Compared to other native apps on the same system: App Main PID Uptime Avg CPU Main MiB Total MiB
------------ -------- ------------ ------- -------- ---------
Cascade 45314 6d 17h 45m 1.52% 73.0 556.8
Proton Drive 22091 11d 04h 32m 0.15% 48.0 65.1
Ghostty 78285 27d 22h 03m <0.01% 173.6 184.2
Finder 1308 34d 19h 32m 0.05% 104.4 104.4
so, if I rewrote the application into three separate applications I could probably save ~200 MiB of memory footprint. I'll look into my ability to slim down the memory utilization but some chunk of this is probably the message buffer of each channel.I long to bring this back in a Miranda-IM way (super customizable), but other projects get in the way.
I don't care if only a handful of us (few milly) find it useful.
- most of the jank of IRC is client-side and can be fixed on the clients, IRCv3 protocol changes are nice, but not essential for a good experience.
- bots can make channels more engaging, just posting the titles of URLs pasted on the channels so even people without fancy rich clients can see what's behind a YouTube link or Reddit share url without clicking it open makes the experience more "discord/slack-like"
- IRC bots and clients are super fun and easy first projects for any language, you get to do permanently open sockets to multiple destinations (multi-server of course), asynchronous stuff and text handling.
I went with IRCCloud for the longest time myself until early this year, due to the November Revolution of AI models getting super good, I figured out I can build my own IRCCloud just the way I like it with the price of a single Claude Pro subscription.
And so I did. I think I had an MVP running in a week (evenings on my free time) and over the summer I cancelled my IRCCloud subscription and I'm fully using my own system.
Now I have a TUI, Web UI, native Swift client (with iOS, but haven't tested it yet) and a Tauri client for Linux - all sharing a common backend that I run on a VPS 24/7.
I've set up an ergo^1 server for experimenting. Channel history is currently in draft stage; and maybe it will be forever.
If any of you want to drop by for some reason and want to try it out: #hn on exp3.irc.basilikum.monster:6697
See here for a list of IRCv3 capable clients (draft/chathistory for history support): https://ircv3.net/software/clients
Anyway, you are right. But that's more about Ahoy and less about Parley. Parley was just answering the question of "What if IRC was federated, and what if it borrowed some ideas from Salty.im -- DNS discovery + WKID".
> A federated network is a system where independent networks, servers, or organizations agree to follow common standards so they can talk to each other without giving up control to a single central company.
In traditional IRC networks, you end up forming a spanning tree of servers that belong to a common name, "the network". However control remains in the hands of the operators of that network.
To be sure, Discord "servers" are not servers in the sense the word is used in virtually every other context. They are more like group chats that share a hosting location. If anything the hard part for Discord is making them seem disparate enough that someone might rent their "own server".
irc federation is entirely different. with federation client support for multiple servers is not actually needed. those features are orthogonal.
Message History
Channel Discoverability
Attachments
Mobile
Anyone can start a server
Multimedia transfer is still a practical impossibility, for better or for worse.
Mobile IRC works, sort of, if you don't mind spamming the channel every time you lose connectivity when you drive into a tunnel or when your phone goes to deep sleep. Again, you can set up a bouncer for that.
I welcome the new changes in IRCv3 and hope that one day soon all IRC users will be able to use the features everyone else has been using for fifteen years or so.
Kind of baffles me that people still make chat apps without those.
"Anyone can start a server" is only true when you're lying about what a "server" is. (Or redefining it to the point of usefulness.)
A Discord "server" is just a defined chat namespace. All the Discord chat "servers" live together on the same actual load-balanced VMs or whatever on the physical servers they run.
It's honestly the thing that's annoyed me most about Discord from the very beginning, long before they introduced the ads and the microtransactions and the mandatory doxxing.
It's laden with ads and microtransactions, but if you remove those (shady scripts abound for those who don't want to do it themselves), the UX is one of the best on the market. There's a reason so many alternative chat clients are basically Discord clones without the microtransactions (for now).
Its open source hostility doesn't really change how well it works. You can copy the good parts without the awful parts, like so many people and companies are already doing.
But I am surprised there are no competitors in the space. It’s good but it’s not that good. I guess it comes down to adoption/network effects
The problem with those many alternate chat clients is that they either require self-hosting, making them a nonstarter for probably 95% or more of Discord's userbase, or their lack of monetisation makes them non-viable long term.
What about it makes it terrible UX for you? Feature set seems to get better every year as far as I'm concerned, inclusion of ads aside.
User Settings -> Notifications -> Sounds -> Enable Halloween Sound Pack
This can get especially confusing when people on different clients have divergent views of the same conversation. e.g. some can see the emoji reacts, others can't. some can see "replies", others can't.
We're also discussing ways for servers to provide a fallback to clients which don't support them.
Uh. I feel like this should be something that's done before it's ratified. What if you find out that there is no satisfactory way?
Then i noticed the horizontal scrollbar :-P
* Conversations, Gajim, Dino, Kaidan, things on omemo.top with a passing grade.
Things which are still not default working everywhere would be voice/video call, but if you adjust your expectations to "IRC with file uploads, no need for a bouncer, and encryption" then it's fairly universal to support all that.
People love knocking on IRC but people are still on it, still using it...
that modality is long dead. we still have email but it's not that same ... I however could take mirc from like 1995 and still use everything.
FTP is useful for bidirectional file exchange over the Internet. There are other protocols, but they all have drawbacks. SFTP can be used for similar functionality, but it requires users to have SSH access. SMB and NFS don’t really work so well over the Internet and are a pain to configure for multiple users. For setting up accounts dedicated to transferring files, you really can’t beat FTP (or really FTPS, which is just FTP over SSL).
Security-wise you set it not to run commands (and maybe chroot) and you're done, right? And difficulty-wise isn't granting SSH access very similar to FTP access?
I don't understand the issue.
But in the most common case a "system account" is a line in two text files, isn't it?
Google suggests that some servers can do SFTP with virtual users.
But, seriously, that got me curious. There are many protocols from that early era that are still with us today. NTP, DNS, SMTP, IMAP, BGP, SNMP, NFS, ICMP. If you allow the 1990's as counting as "old" we can add SSH and SSL, DHCP, LDAP.
What we sometimes call SSL is not the same SSL as back then. That said, TLS was released in 1999, so it just barely makes the cut. :D
$ finger a@l3x.in
Also usenet is still very popular but mostly used for file sharing.
The eternal September complaint comes to mind, but even eternal September was a jolly walk in the park compared to what modern social media has turned into.
Spam filtering has improved a lot since the Usenet days, but even if it hadn't we had killfiles to deal with the spam and filtering out harrasers. Doing this today would be even easier with the help of LLMs.
Except, unlike Reddit, it wasn't centralized nor owned by a single corporation.
Usenet users did not have to obey the rules and whims of any corporation and there was thriving ecosystem of feature rich, free and open Usenet clients.
I really miss having my own killfiles and regex search abilities that were common on Usenet clients, but is missing from the Reddit clients and its web UI.
I guess we only have three protocols, email, irc and BitTorrent.
Just imagine hosting that history on your instance for users and then some vibecoder without care in his work starts scanning it automatically every 5 seconds just in case it might have changed...
Future generations are going to be looking at a historical black hole.
More illuminating: To what (relative) extend? And what's the trajectory?
Looking at Google Trends: https://trends.google.com/explore?q=%2Fm%2F03t2s%2C%2Fg%2F11...
gopher is the one that seems really dead. ftp is still pretty common, usenet is still active (though maybe just for "Linux ISOs"), telnet lost its main use which was for remote shells and muds/moos but still use it from time to time for random devices that support it. IRC only had 400 or so active people on it at any given time. I haven't really used it in the last decade. The web destroyed gopher almost instantly.
I think IRC is a neat, and had some fun vibe coding https://github.com/karazajac/switchboard and https://github.com/karazajac/rIRCd
Trying to implement a modern client and server based on IRCv3! :)
Mostly just a personal fun project.
Honestly, I'm trying to remember why we collectively moved away from this. I was terminally online in the 90s and the hadn't touched IRC in many years, but this is... actually quite nice.
Also when discord came out there was a certain appeal to having voip built into the same app, and not having to maintain a separate vent/mumble/ts.
In the 90s it was in game chat, forums, VoIP, possibly an IRC channel. That was a lot of infra to juggle and usually it wasn’t all hosted by the same person. So if xXxDarkNinja69xXx got his feelings hurt he might take down the teamspeak and then your community is up shit creek without a paddle until you can find someone else to host it.
Discord does a merely-okay job of all of that, and possibly Reddit has supplanted the forum bits that discord can’t, but it’s less overhead for the administrators of each community.
I don’t really do any gaming these days so I too don’t use the VoIP, but that was a big part of the allure when discord launched.
(1) It silently disconnects from the server without indication, and does not reconnect. You might assume it is connected, until you send a message and see "message can not be sent". You will lose conversation history unless using a bouncer. Clicking around, all the buffers will clear indicating some major state issue, and you will have to restart it.
(2) Consistently uses ~5% CPU doing nothing at all.
(3) Doesn't behave like a macOS app, pressing the red "close window" button will close the window, but the main process goes ANR.
After leaving Textual since that was discontinued, guess I'm looking for a macOS IRC client again. Might give Mango a try.
But Textual! I just stumbled across this yesterday: https://www.textualapp.com/news/a-new-chapter
TL;DR someone bought Textual and are restarting development. It's not a PE-style purchase, like a Bending Spoons / Evernote kind of thing. According to the buyers, they bought it because they're heavy users and wanted to take it over so they could resume active development. I always keep a healthy skepticism, but I'm hopeful.
I know that's not the fault of the protocol itself, but that's always one of the biggest hurdle for IRC adoption when everyone is used to just open apps and see the full history at all times.
It’s just they need a bouncer (an always online irc server you run) for things like push notifications (and chat history on servers without the chat history extension).
Bouncers (and some IRC v3 extensions on newer servers) allow you to be logged in to the same account from different devices.
I’ve also had some fun writing a bridge from discord to irc for some personal discord servers (but it uses some account impersonation hijinks that make it impractical for other to use).
I'm also extending it with support for Discord/Matrix/etc-esque communities (in a 100% standard-client-compatible way).
So i decided to share it with a couple friends and retro enthusiast communities on Discord. I took a video capture of my engine working, showing the 3d rendering, audio, video, etc with an Xbox->HDMI->USB capture chain. Then attached the file on Discord's input field and posted it (i have a tab with the web UI pretty much constantly open in Firefox). People weren't around at the time but some saw it today and commented while i was sleeping (with my computer off).
Last time i checked, this wouldn't be possible with IRC because:
1. There is no video (or any other file) host on IRC servers.
2. IRC discussions are ephemeral, you either need to be online all the time or setup some sort of proxy that keeps the discussions around while you or others are away (or do what i used to do 15+ years ago - run a terminal-based irc client in a screen session in a VPS :-P).
AFAIK #1 is still impossible and #2 is an optional extension (that i've never seen in real life). Meanwhile i can now connect to a new Discord community and not only not worry about losing any messages while i do other stuff (i often check what people have talk about in Discord since my previous "visit" to be up to date) but also search what people talked about previously - e.g. did anyone brought up some XYZ topic i want to talk about?
IME the above two (also add images and audio to the mix - in two of the communities i'm in there are people who post WIP music they make) are basically 90% of how i see people use Discord: they post something (very often media-based) and very often others see/respond to it in their own leisure much later (in some channels people even live on different timezones so they can't do otherwise).
TBH nowadays if i wanted to set up some community in a self-hosted manned and wanted to stick with open stuff, i'd probably use RocketChat or something like that (Godot uses a self-hosted RocketChat instance that while a bit more janky than Discord, it seems to provide pretty much the same features i mentioned above).
who pays for the storage to keep the file on a computer somewhere, and the network to serve the file to the internet indefinitely? in Discord's case, it's the users
usenet iirc tried to do a sort of "torrent" the data across enthusiasts' / participants' computers?
That said I can't say it's hard to just run irssi inside of tmux and attach/detach as necessary remotely. Nor is it hard to throw my media I'm sharing onto a web server. But yes, you do need to mix and match your utilities, rather than have an all in one package.
I do often enough find this to be more of a feature than a bug -- being stuck with Discord's UI is gross, but the network effect does have me continuing to use it for some groups.
[1] - https://altchan.org/sh/8
Ircv3, the thread title, supports file sharing
Good v3 clients like The Lounge also offer it
With WhatsApp, Discord, etc, that server is provided by Facebook, Discard respectively. With XMPP, Matrix, that server is the instance in which you have an account or where the channel is hosted.
With IRC, you use a bouncer. What makes IRC unique is that a bouncer is _optional_. You can even join a channel without an account and without a server which keeps logs while you're offline. This ephemeral level of joining doesn't exist in WhatsApp, Discord, XMPP, Matrix, etc.
And, btw, this is not a new thing: I first saw bouncers 15 years ago and they weren't even new back then.
All of our comms for https://pico.sh are on irc and we have tons of users join and leave immediately because the room feels cold / dead even tho we were chatting 10 mins prior.
This is fundamentally the main problem with IRC development nowadays. People want IRC to have features but are unwilling to support IRC developers to actually implement them and as a result pretty much every single IRC developer (myself included) who isn't churning out slop is burned out because its a thankless job.
Anyone interested in exploring this segment of the internet, start with: https://netsplit.de/
I wonder if I can find the time to build a native iOS IRC client that follows Liquid Glass, and works as well as Goguma. Not many people would use it, but it’d scratch my own itch, as they say.
The protocol is so simple[1] that it shouldn’t take that long or be that hard[2], I think.
[1]: Which is the beauty of it, ofc.
[2]: Famous last words.
Still, better than Goguma for iOS as far as design goes. I wonder how the features compare through, as Goguma is the gold standard, akin to Conversations for XMPP.
Didn't really look into iOS though, I'll have a think...
So far:
- Swift 6/AppKit built with SwiftPM only, no Xcode project. As a stack of modules.
- The default behaviour is native window(s), but have a classic MDI frame (with child windows inside one main window) that I really enjoy playing with and debugging.
- Behaves "the mac way" (menu bar, text editing, scrolling, full-screen, dark mode, VoiceOver), and anything that belongs to mIRC behaves the mIRC way. Still lots of rough edges though.
- Conversations are tabs in one shared window, the tab bar acts as mIRC's switchbar, the treebar becomes a sidebar. DCC transfers get their own standalone windows as I felt that makes it better as p2p.
- The options, defaults, and menus are an exact copy of mIRC 7.85 - I'll evolve it after "finishing"
- Only the top UI layer touches AppKit, so the parts that have to match mIRC exactly can be tested headless in CI.
- The IRC protocol, session state, mIRC formatting, a mirc.ini-compatible config, a scripting interpreter that copies mIRC's evaluation model (PCRE2 tuned to behave like mIRC's PCRE 8.45), DCC, and the display format strings are all pure Swift.
- Some decisions go beyond mIRC to fit MacOS: an untrusted server certificate is asked the user and pinned, never just trusted. Router port mapping uses MacOS's own port mapper. And also created a few new pixel icon sets I haven't fully decided on.
I prefer the MDI view, but wanted a native option, so showing both. :)
(First time I'm sharing this publicly. The caveat being I'm still unsure if I'd release/sell this as a proper thing, FOSS it, or just keep playing by myself)
I think the main problem there is that there's not really any motivation to build that on top of a simple protocol like IRC. The strength of the protocol is that it's distributed, easy to understand, text based and lightweight and I'd guess most current IRC users are people who use it for a very long time already.
Tucking all these mainstream features that people are used to this days to get feature parity with any other competitor (Slack / Teams / Discord / Matrix etc.) will not make IRC more popular, it will make the protocol more complicated and fragmented.
Good luck with that: https://xkcd.com/1782/
I appreciate its text-only nature and would never want to see image/video embeds and/or voice chat in my client.
I was involved in server-to-server protocol design for a while, and each network had very specific ideas of how they wanted it. IIRC Undernet pioneered the use of timestamps to keep track of channel membership priority, EFnet came up with a v2 twist on the same idea, while IRCNet rejected the approach in favor of some kind of limited server-side persistence. Heady times!
[1] https://en.wikipedia.org/wiki/Freenode [2] https://ircv3.net/wg
- client/server communication is IRC-over-TLS by default when using modern servers, e.g. Ergo, but afaik also Libera/OFTC/etc support TLS [1]
- Ergo comes with a built-in bouncer, you get all the history according to whatever Ergo has set as retention [2]
- client have now support file uploads too [3]
[1]: https://github.com/ergochat/ergo/blob/master/docs/MANUAL.md#...
[2]: https://github.com/ergochat/ergo/blob/master/docs/MANUAL.md#...
fwiw, I was logging in with Quassel for several weeks before I started that project, that needs an OAuth token for the IRC login
At what point do we say matrix isn't going to work? It's been like this for years. It's so overengineered on an immutable chat history on a blockchain it has crossed the line into "way too expensive to run and maintain for streams of cat pictures and memes". Worse is better.
A decade ago Moxie Marlinspike argued[1] that to develop Signal more quickly, he and his team could not be distracted by federation. At the time I wasn't sure what to think, but it does seem that the effort level of using the integrated approach of client/server/protocol may just logistically be easier.
That's is what I mean by not working. Those are things are are either bugs, or as in the falsely banned issue, a protocol design issue that should have been thought through in the first place
I'll happily move over to XMPP or IRCv4 if they can get it right, I'm not married to the way Matrix does things. But it's good enough, open source, and federated.
It's a server side change, robustifying the server-to-server links and its effects on connected clients.
I'm running a Matrix server using https://github.com/matrix-construct/tuwunel as an alternative to IRC, but I missed the lean-and-mean of IRC since Matrix is full on event driven delivery like XMPP/Jabber.
Usually they see it as some cool underground hacker thing and talk about how they wish they could get their Discord friends to use it too. They don't seem to stick around long-term, though. I guess the novelty wears off and they go back to where they came from.
Then again the culture is different with IRC versus other platforms and people adapt with not having a full chat history, so dunno if this is an actual issue in the long run.
So yeah, we are going to have the Dyson swarm before this is done.
Mostly complainers who would rather see IRC stay the same. Right now one of them is complaining the author is a vibe coder, as if that somehow makes the critique that IRC continues to be far behind everything else less real.