Râu Cao ⚡

Did a little Nostr talk at a small bitcoin meetup with mostly non-technical users last night, as they asked for people to talk about stuff they're building with it.
The idea was for builders to talk about their projects. But instead, I had to give a general Nostr 101 talk, because only about a quarter of people had even heard about Nostr before, virtually nobody used it regularly, and there was also no other speaker present.
Observations:
* People who were aware of Nostr were also much more interested than the others. They mostly had the usual questions:
** What about spam?
** It feels like Nostr has lost all traction (following users who aren't posting anymore)
** Is it possible to get an endless stream of interesting posts? ("I'm used to doom-scrolling")
** How many relays are there?
** How difficult is it to run your own relay?
** What if one company (e.g., Primal) gets to "control Nostr" through market share?
* And a couple of new ones for me:
** Can I spam people's inboxes for profit (i.e. mine relays for user interests, then target users with DMs)?
** Has someone built a DEX order book on Nostr yet?
Generally speaking, Nostr was still perceived as social media only. Which makes sense, because the least experimental clients are focused on micro-blogging, of course. I did explain the Other Stuff, and also demo'd my blogging software, but the questions and interest were almost all about the social media use case.
Most of the evening felt a bit like talking about the fediverse in 2018 or so. Now you just point to Meta having a Fediverse timeline in Threads, and there's simply no question that the protocol is useful to enough people that a company of that size would add it to their product. It also went through the same waves of adoption, where people brought a lot of followers to the protocol, only to then stop posting and make the place feel empty for those followers. And with every wave of adoption, more people stay and make it more interesting for the next wave.

2025-06-19 06:59:29 UTC

- reply

Let's re-build Dopplr!

2025-06-18 11:05:32 UTC

- reply

I hope not, because I don't want Nostr comments to look like we're on X:
https://image.nostr.build/179d9a85a044262f84f3520e854a0756322ad1fe6f0c1a6b0cc5c40d75ca1061.jpg

2025-06-14 11:41:20 UTC

@npub1zuu…c2uc FYI: https://swicg.github.io/activitypub-e2ee/mls
The absolute dream would be if the early proposals could eventually become interoperable across protocols (so we can bridge users and it doesn't matter where they are), before widely deployed. Not holding my breath, but one can dream.

2025-06-11 15:51:47 UTC

- reply

I'm tempted to say yes only to fix my posts not being bridged to fedi anymore and then immediately quit again. 🫣

2025-06-01 14:08:06 UTC

- reply

It's a blessing and a curse.

2025-05-26 15:04:24 UTC

- reply

I just made @npub180c…h6w6's point about not requiring the type for him, by mistyping the content type in my own post. It's "application/nostr+json", of course.
https://image.nostr.build/da4515d21ee9103910fd96370cbb740a2fe1985c0c20a9219e87cac37f71918a.gif

2025-05-26 12:25:37 UTC

This is now part of NIP-21: https://github.com/nostr-protocol/nips/blob/master/21.md#linking-html-pages-to-nostr-entities
So if you render Nostr content somewhere on the Web, or you just want to link your Nostr identity on your personal website in a machine-readable way, then consider adding the respective link tags to your HTML markup.
(Personally, I still prefer adding 'type="application/json+nostr"' to the elements for maximum interoperability, but it's optional.)
#nevent1q…vyfr

2025-05-20 06:20:46 UTC

- reply

Both Meta and Automattic (WordPress) announced ActivityPub support before Elon purchased Twitter, and the fediverse had already seen multiple big waves of user influx at that point. Not even mentioning the countless papers written about it, or the many different implementations in existence by then. I think there were about 25K active servers/instances in late 2023.
It was Bluesky that grew massively after the Elon purchase.
Either way, the important takeaway is that large-scale adoption can only happen when you already have a healthy network running, and it has enough users on it to be interesting enough for newcomers to stay for longer. Posting exclusively to the networks you want to grow, instead of cross-posting to the networks you want to shrink, is the best way of creating that sustainable base.

2025-05-19 05:10:51 UTC

- reply

... and WD-40

2025-05-18 16:28:43 UTC

- reply

Please share here as well then. Thank you. 🙏

2025-05-18 06:18:46 UTC

- reply

No, I think multi-sig is overkill. Relays are places, sure, like you can hand over a newspaper on a town square.

2025-05-18 05:22:19 UTC

- reply

This has been on my mind since I asked that question, because extending my blog software with support for publications is still my goal. However, after observing and dabbling in Nostr dev and specs for about a year now, I'm more convinced than before that relays are the wrong abstraction for publications. I haven't engaged in more discussion yet, because I was both trying to solidify my understanding of why, as well as come up with and implement what I think is a decent event-based solution.
That said, I think relays could be useful for indexing/curating publications themselves (while users should also be able to index/curate them separate from relays). Either way, demo and article incoming (soon-ish).

2025-05-15 12:32:28 UTC

- reply

Because freezing funds for a single address is not possible?

2025-05-09 10:11:09 UTC

- reply

Not sure about you, but I prefer the ground I'm standing on not to be at the edge of an abyss.

2025-05-08 18:16:23 UTC

The OP_RETURN "debate" of the bitcoin "community" is an excellent demonstration for why X is an abysmal neutral ground as a public square.

2025-05-08 12:19:03 UTC

- reply

It's the other way around. If you want txs that are being mined today to stay out of the mempool, you're making life harder for new and smaller miners, and you're incentivizing profits outside of the open fee market.
https://spiralbtc.substack.com/p/the-mevil-of-relay-policy

2025-05-04 20:48:17 UTC

- reply

Yes! The unwritten rules for taking photos of your road bike are: cranks parallel to the ground and gears in biggie smalls. 😅

2025-05-03 07:07:44 UTC

- reply

Officer, I'd like to report a crime against cake.

2025-05-02 09:35:51 UTC

@npub1q3s…d26p Any chance you could have a look for why my posts don't get published by mostr on fedi anymore? I'm sure there must be more accounts if it's happening with mine. Last published one (or at least the last one ending up on my instance) was in January this year...
(I'm broadcasting all my stuff to the mostr relay, so that's not it.)

2025-05-01 07:58:25 UTC

Bitcoin will definitely die, because of a change in bitcoin core that doesn't change consensus rules!
One more death for https://bitcoindeaths.com

2025-04-30 09:00:14 UTC

- reply

I meant a simple solution that actually works today and just switches discovery by user address from lnurlp to bolt12.
You can chase your name service holy grail regardless of that.

2025-04-30 08:32:15 UTC

- reply

How do I discover your BOLT12 from a human-readable/memorable name now? Is there a spec for that? Should we add a simple entry to Webfinger perhaps?

2025-04-29 19:18:42 UTC

- reply

Good to know, thanks. Would it be enough to have it in a namespace on one of the two?

2025-04-29 18:33:00 UTC

- reply

The docs are here: https://jsr.io/docs/publishing-packages
I would try one of the manual options first, but it's also easy to do from a GitHub Action later: https://jsr.io/docs/publishing-packages#publishing-from-github-actions

2025-04-29 18:29:35 UTC

- reply

Nice!
Would love to see it on JSR, since it's all TypeScript anyway.

2025-04-28 16:27:06 UTC

- reply

I'll never understand how someone can walk around without cash and trust their card, or even worse their phone, to always work. But the same goes for businesses not accepting cash, of course.

2025-04-28 09:52:37 UTC

Not sure if I did this right, but I'm accepting issues and PRs for the Nostr Links extension via Nostr now:
https://gitworkshop.dev/raucao@kosmos.org/nostr-links/prs
Original repo here:
https://gitea.kosmos.org/raucao/nostr-links

2025-04-27 07:03:28 UTC

- reply

Just a note on CI solutions:
For https://gitea.kosmos.org we use Gitea Actions, which is compatible with GitHub Actions, like you describe.
https://docs.gitea.com/next/usage/actions/overview
It works nicely, and the configuration allows to configure both hosted and external runners per repo, user, or org. (Meaning you don't have to allow just any user to run arbitrary payloads on your infra, but you can allow only trusted or paying users to do it.)
Being compatible with GitHub Actions brings baggage, but also convenience and less migration work, of course.

2025-04-26 13:28:11 UTC

- reply

Sorry, you didn't. The type should be `application/nostr+json`, not `application/json+nostr`, as per https://datatracker.ietf.org/doc/html/rfc6838#section-4.2

2025-04-25 20:14:19 UTC

- reply

Nice!
The HTML is currently missing link rel elements for feed discovery. Something like this:
`<link rel="alternate" type="application/atom+xml" href="/npub1n00yy9y3704drtpph5wszen64w287nquftkcwcjv7gnnkpk2q54s73000n/rss.xml" title="No Solutions Podcast" />`
Incidentally, I also just proposed adding alternate Nostr links to Web content with Nostr representations, as well as to feeds, and some people seem to like it, so you could also add those:
#nevent1q…t4hq
(For RSS, the elements need to be namespaced, for example `<atom:link rel="alternate" ...`)

2025-04-25 19:49:51 UTC

- reply

Hmm. In my implementation, I just do a single query to fetch articles for an npub, and then order them by `published_at`. It's very simple and works pretty well.

2025-04-25 15:45:47 UTC

- reply

I was actually wondering why you don't just configure an npub and maybe a tag for filtering if necesaary.

2025-04-25 14:04:21 UTC

- reply

That depends on the implementation of discovery mechanisms. My extension would probably miss injected elements after page load at the moment.

2025-04-25 14:02:15 UTC

- reply

The argument parsing with the commas was only broken in tmux for me, but works fine with the latest nak now. I have no idea why or how that would happen.

2025-04-25 13:29:24 UTC

- reply

I'm also using front matter for publishing NIP-23 content. If someone else implements that in a proper tool, maybe we can use the same keys:
https://nostr.kosmos.org/@raucao/2025-04-24-markdown-to-nostr

2025-04-25 13:28:16 UTC

- reply

Not yet. I'm not sure it even warrants a NIP, since it's basically just using the HTML spec as intended. But maybe there should be one.

2025-04-25 08:31:31 UTC

I also just added the link rel elements to my Atom feed. So if you have a feed reader with both RSS/Atom and Nostr support, and someone adds a URL for the former to your reader, it could now detect the Nostr alternative and offer the user to subscribe to that instead.
Also interesting if some of the feeds you're already subscribed to (maybe for much longer than Nostr even existed) started adding alternate Nostr links in the future, so we could slowly migrate to a more decentralized system.
Maybe something for noflux, @npub180c…h6w6?
#nevent1q…dqcs

2025-04-25 08:17:54 UTC

- reply

Will merchants continue to pay between 3 and 9% fees to the debit card oligopoly with that?

2025-04-25 08:07:39 UTC

Turns out that @npub180c…h6w6 fixed the issue with the commas a while ago. So if you just use the latest version of nak with this, then all is good. 🥳
#nevent1q…57qv

2025-04-25 08:04:47 UTC

- reply

Oh, also, you can even add them to RSS and Atom feeds, like so: https://nostr.kosmos.org/@raucao/articles.atom
For RSS, the elements need to be namespaced. I would use `<atom:link rel="alternate" ...`.

2025-04-25 07:45:44 UTC

- reply

Nice!
May I ask you have a look at https://nostr.kosmos.org/@raucao/link-rel-nostr and consider adding the link element to your generated HTML?

2025-04-24 11:48:43 UTC

Here's the bash script I created for publishing NIP-23 content. Maybe it's useful to someone else:
#naddr1qv…sm2s
I'm only aware of a single issue right now, which is that nak doesn't seem to like commas in tag content. Other than that, it works just fine for me.

2025-04-24 08:59:23 UTC

- reply

By the way, if you have a personal home page or profile page, you can also add your npub to it this way. The link can be to any Nostr address/ID.

2025-04-24 08:52:06 UTC

- reply

Standardizing it in a NIP is good, but doesn't help with people using it wrong.
It's funny (and sad) that both of the issues in the original post there just stem from using Markdown wrong, and have nothing to do with Nostr or interop. Newlines without double spaces mean nothing in Markdown (for good reason, so you can format your source document better), and the image syntax is just plain wrong.
Clients should obviously at least implement Markdown rendering according to the Markdown spec, if they're not using a library that does it for them.

2025-04-23 15:18:11 UTC

This is a small thing, and the demo case is kind of silly (because there's an open-with-nostr button under the articles it's currently working for). Nevertheless, if you publish articles on the Web as well as on Nostr, would you consider adding this HTML element to your pages?
https://nostr.kosmos.org/@raucao/link-rel-nostr
Also, if you're working a Nostr client that renders previews for linked content of any kind, you might want to parse that element and adapt your UI for Web pages that tell you about Nostr versions of their content.
Also please do let me know if you think I'm doing things wrong, or if you have any other kind of feedback. Thanks!

2025-04-23 15:08:54 UTC

- reply

Yes, I'm not overly happy with that either. I wrote my own article rendering for public HTML pages on our relay and there were quite a few edge cases from inconsistent usage to work out, too. Some clients repeat the title in the content for example. Lots of small issues like that. :/

2025-04-23 10:33:45 UTC

OK, so Habla lost a draft of mine (and its whole relay page/loading is broken for me now) and I wasn't able to load it in any other client for long-form content either. The NIP-23 ecosystem in general is just rather messy and buggy.
So I ended up creating bash scripts to export all my drafts to Markdown files, with meta data in frontmatter format, as well as publishing updates from those Markdown files via nak.
(I hope the Deno folks release Fresh 2.0 soon, because I'm waiting to port Substr to it and actually add a decent, non-buggy publishing UI.)

2025-04-21 17:51:21 UTC

- reply

(I mean zap wallets *and Nostr clients*.)

2025-04-21 17:49:44 UTC

- reply

Wallets that support zaps should offer notification settings for threshold amounts, as well as zaps without a message for example. It's a very simple feature to implement.
Here's an example from Kosmos account settings:
https://image.nostr.build/5a8d2e87d16f75a23a1bfa42774c3fde3583ef4bda7b093a550a4f61f0a580a1.png

2025-04-16 10:21:59 UTC

- reply

It's almost as if their DIDs aren't actually D.

2025-04-13 07:05:45 UTC

- reply

Not really relevant, because broadcasting the tx works fine. So it's only about what other full nodes are willing to accept from me.

2025-04-12 07:24:42 UTC

- reply

Great idea! 👏
Just FYI, your git host is throwing 429s for me after only a few requests. I know, AI scrapers are terrible these days, but the current request limit is too low for not shutting out real users.

2025-04-12 06:08:07 UTC

- reply

Nice! 👏
Where to submit PRs for content?

2025-04-08 12:20:10 UTC

- reply

Not even relay.
Also, all the popular blockchain services' nodes seem to have `minrelaytxfee` set above 0 these days (either from default or explicitly).

2025-04-08 11:02:41 UTC

Apparently, absolutely nobody wants to relay a zero-fee tx from my node. Where have all the plebs gone?

2025-03-27 09:30:02 UTC

- reply

Can't wait for the cosigning to finally be reliable. 👌

2025-03-25 21:06:24 UTC

- reply

Europeans against tariffs 🤡

2025-03-18 13:08:15 UTC

- reply

Isn't that what Common Law is?

2025-03-18 06:16:05 UTC

- reply

Everything Everywhere

2025-03-11 05:18:33 UTC

- reply

Ever heard of Volkswagen, the official nazi car?
https://image.nostr.build/cc23d362ea07fb499dc54f1649549c7e3da653ac1a0d46748c55626e1003c087.png
(Not even mentioning concentration camp labor for Mercedes, Bosch, etc.)

2025-02-23 06:46:18 UTC

- reply

As soon as I discover one that doesn't do data (incl. not anymore), the scissors come out. Can save your future self a lot of time.

2025-02-21 13:23:02 UTC

- reply

"thriving" 🤡

2025-02-21 07:49:35 UTC

- reply

I streamed sats to something in real-time once, and absolutely hated the experience. Minutes listened are just never equal to value derived.

2025-02-12 08:02:12 UTC

- reply

When strfry 1.0 on https://relay.damus.io ? Would love to be able to negentropy-sync again...

2025-02-10 08:58:31 UTC

- reply

https://image.nostr.build/5aabfdcf78041abc4c0f10a5a841d6351dfcfaaab5a7a56715fbe7a53c6eae2f.gif

2025-02-07 10:28:16 UTC

- reply

My posts from the fedi side are still not showing up again on the Nostr relay, though...
#nevent1q…95nc

2025-02-05 09:12:43 UTC

Wild!
https://image.nostr.build/560aee989d25895c03dd1e738e3c6d89627114aec4b7dd3abf4c01293b1a32bc.png

2025-02-02 03:36:28 UTC

- reply

It guarantees that the number of new artworks they can publish stays zero, i.e. absolute scarcity.

2025-01-29 15:28:27 UTC

- reply

https://image.nostr.build/370d3b7d813b1450a994bf28338b0d732d20518913bbf8c9a37fdeb9d6f18d7b.png

2025-01-28 23:25:02 UTC

- reply

(Posts from https://kosmos.social/@raucao to Nostr, not the other way around.)

2025-01-28 23:23:31 UTC

@npub1q3s…d26p Looks like mostr.pub has been missing my posts again in recent days. Not sure how to debug or help from my side, other than playing uptime monitor...

2025-01-27 13:41:42 UTC

- reply

"Imagine one app that..."
https://image.nostr.build/136308c279c622a883eb4e0b94e5814390074de62ee885dc95f41b8ce0dd6904.gif

2025-01-24 22:03:45 UTC

Who of you left this sticker on a a directional antenna on Carenero?
https://image.nostr.build/77b97ac8e3da7b513a9271ba53aed013005664a243d8f903257da68ade13d2e1.jpg

2025-01-23 19:24:31 UTC

@npub145l…9hce https://image.nostr.build/39f94054df90aa6e48cb7b8bbbfbae6bbb704cfd1a3766e2cfc34997fa5d102b.png

2025-01-18 15:19:22 UTC

GM
https://image.nostr.build/1d1f1f42528d53fa8c337c4b493ccbb5059c9872edb11a97c540d2f489989d8a.jpg

2025-01-16 20:22:03 UTC

@npub1vad…nuu7 This is an interesting idea, that I tend to agree with:
"In matters of the large scale, then, not only are we cogs in the machine, we must do our best to treat others as cogs in the machine and not special, in order to be appropriately ethical and to build societies that actually work for everyone's benefit."
https://reyify.com/blog/the-fallacy-of-agency/

2025-01-16 18:02:20 UTC

- reply

Agree. Having implemented it for our custodial wallet (with additional relay integration, so our users don't miss a zap, regardless of which relays the sender uses), I must say it was hilariously complex for not even having a guarantee that the payment happened.

2025-01-15 17:49:19 UTC

- reply

Humans are just unknowing agents of entropy. Just because you're conscious enough to observe your actions does not automatically mean that you have free will, which would require some kind of soul outside of your brain/body and is thus a religious/spiritual idea instead of a physical one. Thus, any human actions that influence bitcoin transactions are also just the result of atoms banging against each other since the beginning of the universe. And bitcoin simply exists within the same universe, with all the same rules of physics, for all we know right now.
Don't overestimate your mind.

2025-01-15 17:00:29 UTC

- reply

I think I found an issue, which is that AFAICS it will send the next sats directly to the last used withdrawal address. If so, it'll send it to an address that I don't actually control, so it should let me change the address explicitly, without requiring a withdrawal at the same time.
Or maybe I understood it wrong, and it always stays in the custodial wallet until claimed?

2025-01-14 16:13:19 UTC

- reply

I'm rich now!
https://image.nostr.build/3189590bd92bcfb04c90efa6d77af846bdf39fc8e99cf641367dd789c71d9746.png !

2025-01-14 14:58:55 UTC

Imagine being someone at a "Social Web Foundation", writing about "algorithmic pluralism" and against "corporate-owned spaces", and the only two protocols you consider as open social technology are: one defined by a corporate consortium, and another defined by a single corporation and run exclusively by it at the moment.
The silence about Nostr is deafening.
https://socialwebfoundation.org/2025/01/13/free-our-feeds-and-algorithmic-pluralism/

2025-01-14 14:25:19 UTC

- reply

https://image.nostr.build/43c4c61bbf6a23f7b323f1edc68bef495e9e8cde2de4cb5589a44e9cabf6bdbd.jpg

2025-01-03 18:34:23 UTC

- reply

I want to implement multi-author blogs on Nostr. For example for our opensource co-op. The authors should be able to tag posts for one or more blogs, and the co-op key should publish who's allowed to post. When our relay goes down or loses DNS connectivity for whatever reason, everything can still be accessible from other relays. Clients can also cache whatever they want.

2025-01-03 16:50:47 UTC

GM
https://image.nostr.build/c2950fc07f0260061b99868a1955ad7f85e1e4829411301a85facc1df1f8df93.jpg

2025-01-03 15:43:35 UTC

- reply

A publication is a collection of content from various authors/creators, usually with the permission of the author for their content to appear in it. Personally, I would not call user-curated collections like e.g. on Flipboard a "publication", since the idea of a publication is for content to be first published, not merely shared, listed, or linked.
The potential censorship risks of DNS have absolutely nothing to do with publications not publishing everyone's articles. Not sure what you meant to say there. I meant that when events are spread across multiple relays to begin with, it's much harder for people to lose access to content, when a single relay goes down for whatever reason (can also just be infrastructure issues).

2025-01-03 15:37:52 UTC

- reply

It means to fetch and render events created/signed by a specific key. In this case, all article events. The author has no control over who fetches and syncs their stuff. I sync your articles to our relay for example, then subscribe from there (currently via RSS, because I haven't tried out Narr yet). There are also caching relays, mobile relays, etc.. This is why tying anything to a particular relay seems like the wrong approach to me.
Also, relays are identified via DNS and don't additionally sign content, so without any kind of tag mentioning the publication (in that case the relay), the author's intention for being published there is not clear.

2024-12-29 20:57:41 UTC

- reply

Hmm. I always thought the basic idea of Nostr is that events are not tied to domain names or URLs or anything of the sort. Off the top of my head, I see 3 issues with this special-relay approach:
1. It diminishes censorship resistance
2. Seeing publications tagged (and linked) in articles before having subscribed to a special relay is good for discovery. I would definitely want people to be able to subscribe to all my articles by just subscribing to the pubkey itself.
3. It adds a burden on publishers to run special infrastructure

2024-12-29 17:08:19 UTC

@npub180c…h6w6 Have you thought about NIP-23 feeds for publications instead of pubkeys?
I.e. one could subscribe to a feed of a specific blog that multiple authors write using their own pubkeys. Most blogs in my RSS reader work like this, and I think it's crucial for NIP-23 to be as useful as it can be. The cool thing about Nostr feeds vs normal RSS feeds is that the content would be properly attributed to each author and can be gathered and rendered outside of a centralized blog/feed as well.
I was thinking about creating a new kind for announcing a "publication" (i.e. blog, magazine, etc.), which holds metadata similar to a kind 0 profile (display name, avatar/icon, description, ...). The pubkey "founding" the "publication" would then add tags for authorized author pubkeys, so clients could verify that when a kind 30024 article is tagged with one or more publication IDs, it's not spam or impersonation.
One problem with this (and with a system without time in general) is that when a founder would remove authors later on, it would appear as if they never wrote for a certain publication. But I'm not sure it's actually a problem in practice.
What do you think? Maybe I'm thinking about this all wrong? Or maybe someone has solved this already?

2024-12-29 12:23:51 UTC

GM from wintery Bogotá.
Not far to @nprofile…p78w now.
https://image.nostr.build/0f537cf986281c23f7a4383469c699381ebd691d646c914faf3fb4f47076b12e.jpg

2024-12-25 15:49:33 UTC

MC
https://www.youtube.com/watch?v=pfiCNAc2AgU

2024-12-24 14:15:06 UTC

"True freedom isn’t just about living for oneself. It’s about building a future where individual sovereignty is enriched by collective purpose"
https://globalnatives.substack.com/p/what-freedom-really-means-from-sovereign
This resonates a lot with me. Probably because I've been living as a sovereign individual for well over a decade now, but have also been helping to build both a co-living space and a co-op over the last few years.

2024-12-23 06:30:52 UTC

GM
https://image.nostr.build/45f2aad15fca3ba3a5875c04cca0460473b2c4747e161821dd27160328514e3b.jpg

2024-12-20 05:35:26 UTC

- reply

Scrooged, Die Hard, Bad Santa. (In no particular order.)

2024-12-20 04:17:56 UTC

- reply

Opening a lightning channel is just a normal bitcoin transaction. So the fee goes to the miner who mines the block, same as with every other on-chain transaction.
If you buy an incoming channel from an LSP, then they charge a fee that is usually a bit higher than the pure tx fee. But if you spend through your own channels first, you can create incoming liquidity for free (i.e. the overall amount you spend).

2024-12-19 05:15:31 UTC

- reply

Called it:
#nevent1q…z6ve

2024-12-18 10:35:46 UTC

- reply

Cool idea for rendering the balance as both BTC and sats at the same time!