Surgical devices like the ones used to go through tiny incisions in the abdomen and seal vessels

Design for manufacturability mostly

But now I’m getting deeper into Python and enjoy working with Bitcoin and Nostr libraries so I want to put more energy there

What about you?

I am tempted in the opposite direction

Change can be good

New challenges await

But will it have gifs?

Anybody else have missing mention/reply notifications on nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg ?

I see notifications fine on other clients

But there’s definitely a mismatch

The DVM currently only does Speech to Text for Nostr events, but I can update it to work with urls if the PDF is available online

Full disclosure though, the cost is $0.36/1000 characters (not words) so for a full length book it could be more than $100 depending on the length

Reminds me of when nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc discussed applying the business model for games that monetize skins, themes and customizations and applying it to Nostr development

Is Amethyst still Android only? I don’t see it on the App Store for iOS

Can you do a screen recording of your current workflow to post gifs? I’m curious how long it takes

I have the gif keyboard from Tenor but even when I copy to clipboard, I can’t even paste to my note; I have to save to photos first and then upload it as an image

It’s so brutal so I’m wondering if you have a faster path

Has anyone thought about the marriage of WebRTC and Nostr?

If Nostr adds audio and video calling to its message and money transfer services then phone numbers are obsolete. Like a decentralized, open-sourced Whatsapp that can maintain anonymity.

From my limited understanding, WebRTC requires a "Signaling" server to manage the peer-to-peer connection.

Would this become a client-side integration?

A Data Vending Machine?

Or is there another way to do this entirely?

I mostly agree, but I get stuck on this sometimes:

publishing a DVM event, listening for a reply, paying the invoice, and then publishing the result is slower than a traditional API.

It's a tradeoff in that an API requires setup, login, credit card info in order to have "faster" calls.

Are you expecting to convert ecash->lightning->usd->stripe?

Wouldn’t this require a lightning exchange on the backend like Strike and then have the USD bank account on Strike ACH to Stripe?

Or how do you see that workflow going?

Replace phone numbers with npubs

Allow calling

Video chats

I expect the start would be encrypted messaging and group chats

Permission-less voice and video communication

GIFS!

If I build a script that takes common meme searches (like “lol”, “angry”, “wtf”, etc) and associates the search term with a Tenor gif result and then posts it as a Kind 1063, would that help to get this going?

Like this? The NIP doesn't spec how tags for search should be included. Do you expect this to be under "alt (optional) description for accessibility" or should the NIP be updated to permit such search terms?

['EVENT', {'id': 'dac293072f3c67d2e0448dfaf6e0403c93681e643944c616ef25827246141234',

'pubkey': '7c3be2769c76eecd6c6e27276722dfae0d8ad201825253452153b90093c41654',

'created_at': 1719985905,

'kind': 1063,

'tags': [

['url', ''],

['m', 'image/gif'],

['x', '5a492e2cc6408086593e4a6bca6f3af604297918e200ed828b842818710a5548'],

['ox', '5a492e2cc6408086593e4a6bca6f3af604297918e200ed828b842818710a5548'],

['size', '28257'],

['dim', '203x200'],

['thumb', ''],

['image', '']],

'content': 'liotta mock laugh',

'sig': '538058211c516ef7edb07fdb4fcfb65e8883c7a225f336993124911f49bcdaf0eeb70a4b281cfd7cc1d0963b98cdb1d768ef7fa07b905cb3d8c662904a658d42'}]

I like the idea of classifying file metadata so that it can be parsed in a search, but the NIP itself doesn't solve the original repository problem, right? By this I mean, where do we find the gifs to feed event kinds 1063? That's where I feel like an a supplementary service is needed to start (e.g. Tenor, Giphy, etc). Let me know if I'm thinking about this in the wrong way.

What do you have in mind?

Could someone create a proxy service for you using Tenor as the backend and allow usage of the proxy service without any identifiable information?

This service could even cache some requests to limit the API calls to Tenor

Could be open source and verifiable

What else do you need?

I see what you’re saying, I just don’t know if that’s “enough” for client developers to adopt it, but I can try it out and see how it goes

Thanks for the back and forth, if you have any other recommendations let me know

I’ll open source it so it’s transparent on what’s going on, but should be really simple 👍

So you’re thinking basically a simple HTTP GET request API for clients to use, yeah?

And then on the back end I can use Giphy or Tenor or whatever gif API service provider, but then open source it to show that search results aren’t stored/sold/paired with user data?

I just don’t want to have to build out my own gif repository; I wasn’t even planning on charge for the service

I just want gifs

I’m inclined to agree, but it is funny that the two first people to reply said different things

I was more probing to see if anyone has had thoughts on a Gif DVM before and if there’s any down sides I might be missing

Mostly concerned about speed right now

I was thinking that originally, but I don’t think the event range 54XX is exclusive to nostr search as much as that’s all that event range has been used for so far

I’ll work on a mock up tonight; hoping to get it around the speed you have on Noogle, but I’m concerned that the time to have Client publish request->DVM api call->DVM publish result->Client render result might be too long