Hacker News new | past | comments | ask | show | jobs | submit | jknutson's comments login

Love the idea. I’m always finding myself writing little user scripts / browser extensions to extend websites I use all the time, and trying to use an API I found in the devtools network requests page always gets annoying when I have to try and do anything beyond replicating the exact input/output I found in the original request.

Haven’t fully looked through the features/docs, so forgive me if my question is answered in there, but what does support look like for:

- Exporting to Swagger/OpenAPI Spec

- Exporting to generated SDK (I know some tools exist that can generate SDKs from OpenAPI/Swagger, so maybe some of these tools have licenses that are compatible with your product?)

- Support for URL path variables (e.g. `/users/{user_id}`)

- Support for URL query parameters (and filtering for common “noise” parameters, e.g. Google analytics)

- Support for non-JSON input/output (e.g. an endpoint that accepts multipart form data)

Awesome idea though. I’m definitely going to try this out. Beautiful UI and website too. I’m stoked to play around with this!

reply


I'm glad you like the idea! Let me answer your questions one by one:

- Exporting to Swagger/OpenAPI Spec: Currently, exporting to Swagger/OpenAPI isn't supported, but it's on my to-do list to look into. Right now, JavaScript code is the only export format.

- Exporting to a Generated SDK: Same as above. I'm considering integrating tools that can generate SDKs from OpenAPI/Swagger specs, so this might be included in a future update.

- Support for URL Path Variables (e.g., `/users/{user_id}`): Yes, API Parrot supports URL path variables!

- Support for URL Query Parameters (and filtering out common "noise" parameters like Google Analytics): Yes, API Parrot supports URL query parameters, and there are measures in place to filter out the noise.

- Support for Non-JSON Input/Output (e.g., endpoints that accept multipart form data): There is support for non-JSON input/output formats, but multipart form data isn't supported at this time. You can find all the supported data types on this page: https://docs.apiparrot.com/docs/tutorial-extras/exchange-mod...

Thanks again for your support! I'm excited for you to try it out, and I'd love to hear your feedback after you've had a chance to play around with it.

reply


3 ways to declare functions? I am probably blanking but I can only think of:

``` function foo () {} const foo = () => {} ```


    function x() {/* ... */}
    const x = function() {/* ... */}
    const x = function foo() {/* ... */}
    const x = (function() {/* ... */}).bind(this)
    const x = (function foo() {/* ... */}).bind(this)
    const x = () => {/* ... */}
    const x = () => /* ... */


Apart from hoisting (which has little to do with functions directly) and `this` these are all equivalent


Not sure if it counts but there is `new Function("return x;")`


Doesn't `function* ()` count?

After all, you can add a `*` to any existing function without a change in the function or its callers.


4 ways


5 ways, the arrow functions have two different syntaxes:

  () => { return 1; }
  () => 1


That’s still one way - arrow function.


Well, these have the same result, so if the two types of arrow functions don't count as different then neither should these two assignment versions:

  const foo = (function() {}).bind(this);
  const foo = () => {};
Edit: And speaking of assignment versions, there's a new comment that adds a third of the same. I kinda get the feeling a lot of the "multiple ways to declare functions" is just people who don't understand how the pieces of javascript fit together and think these are all independent. They're not. Just declaring a function has only a few ways, but declaring a function and giving it a name multiplies that out to some extent.

In javascript, functions are first-class objects: they can be assigned to variables and passed around just like numbers or strings. That's what everything except "function foo() {}" is doing.


`const foo = function() {}`


Do function expressions count?


const x = { foo() {} }


Perhaps it could be misaligned incentives? The primary variable YT optimizes for is time spent on the platform. Being able to instantly find and skip ahead to the part you wanted means you didn’t spend the extra time that you would’ve otherwise.

Granted, I can’t see this specific feature really moving the needle one way or the other. But, internally, they might apply some sort of lens to their decision making that asks “does this increase or decrease time spent and eyeballs monetized?”, and if that is the case then there is a real argument to be made that this feature would not meet the standard for a “good feature”, based off that criteria.

Probably more likely that their entire UI is just so deeply fine tuned and A-B tested that any individual change to it has a lot of friction, lest they push an update that decreases watch time by 0.1%.


would you consider that a dark pattern?


Technically speaking, how do they accomplish this? Given the amount of advertisers they have, the amount of ads that each advertiser is showing, and the amount of variations of those ads that they’re showing (5s, 15s, etc), I think we can safely rule out the possibly that they’re just splicing together an infinite amount of permutations of ads and videos and saving them to disk.

They must be doing some sort of on-the-fly streaming of these ads? It cannot be the case that they’re trying to actually transcode / edit all those different ad possibilities together.


Maybe it’s some sort of in joke for the company. At least, that’s how I took it— alongside it being an obvious reference to a speedometer. My intuition was that maybe the company’s name was “gauge”, or better yet the CEO’s name was gauge. I really hope it was the latter. Makes me think of Hooli from Silicon Valley for some reason lol


I laughed out loud in my office reading the dilbert strip line. Thanks for the giggle, that’s a new one for me lol


Yeah, for real. Isn’t the entire point of cryptocurrency (or at least a key principle) to be resistant to censorship / centralized attempts to “kill” it? I don’t doubt that there is some damage that could be done to crypto as a whole by governments taking steps to “ban” it, but I don’t think we can put the toothpaste back in the tube here.

I suppose the highest leverage card that legislators could play to try to hurt cryptocurrency would be to put a stranglehold on the fiat currency on/off ramps (eg making businesses like coin base flat out illegal), but even after doing that peer to peer markets would survive (albeit likely after also taking some damage to user base, maybe).


If there was no easy way to exchange large amounts of FIAT for crypto and vice versa (other than peer trading with a person), that would effectively make crypto like any other form of tradeable unofficial currency. Gold bars or diamonds or krugerrand. Insofar as crypto is "just" digital cash, it'd still work just fine, but it would make it trickier to move large sums around for criminal enterprises - much like how you'd need to jump through laundering hoops to translate your suitcase of undocumented diamonds back into FIAT, if you didn't have a reasonable answer for how you came to have them.

It'd also put a dent in crypto as a perennial pump-and-dump investment scheme, which in the long run would probably be quite good for its ability to actually work for daily, legitimate use.


I’m not who you replied to, but I agree with his sentiment about signal being superior to telegram in terms of security (or more specifically, privacy).

For me, there’s two big reasons for this:

Signal chats are E2E at all times, while Telegram is only E2E when you explicitly create a “secret chat” with whoever you’re conversing with. I don’t fault Telegram too much for this, because they still provide the option to use E2E for everything, but Signal gets brownie points in my book because they just do it by default without getting in the way of the User.

Secondly, as far as I know, Telegram uses their own in house encryption techniques as opposed to industry standards. I am not at all knowledgeable about encryption or cryptography— I only know what’s required of me in my job (basically the bare minimum), and so I don’t actually know whether this is anything of serious concern. It could very well be that Telegram’s encryption techniques are just as effective as the established norms, but I do see the general consensus trending towards “roll your own encryption = bad, use established norms = good”, which is primarily what I am basing my opinion on here.

To further detract from my own point, it actually seems like Telegram might be using “established norms” for encryption nowadays anyways [1], although I couldn’t really tell from the brief description I read on Wikipedia.

Overall, I think Telegram is perceived as being less secure than Signal primarily because of the reputation Telegram has for implementing their own in house encryption techniques, even if they don’t use those techniques anymore— their name has become associated with their known history of using ad hoc encryption.

[1]: https://en.m.wikipedia.org/wiki/Telegram_(software)#Architec...


Also, Telegram does not even have e2ee as an option for group chats while Signal does. That's a pretty big deal!


I can’t be sure of whether this specific line in their user agreement applies to this specific situation (balance of an account that has been locked isn’t specifically mentioned), but a cursory glance at their (Canadian) user agreement [1] states the following:

“PayPal combines your balance with the balances of other users and invests those funds in liquid investments. PayPal owns the interest or other earnings on these investments.”

(I can’t seem to find a way to hyperlink to selected text on iOS, so I’ve also included a screenshot of this quoted statement instead, below [2])

I assume that (unless stated otherwise in their agreements / legal documents) PayPal continues to apply the same policy to funds that are held by them in accounts pending closure for high chargeback rates. I could be wrong though, I just ctrl+f’d for “balance” on the first legal document linked on their site. Also, only applies for Canada, since I didn’t check any other country’s agreements (but my guess is that wherever it’s not expressly illegal for them to do so, they’ll use whatever money they’re “holding” for you as a revenue generating investment vehicle).

———

1: https://www.paypal.com/ca/legalhub/useragreement-full?locale...

2: https://ibb.co/KXc33RP


I might be out of touch with security nowadays, but could there be a reasonable explanation on Microsoft’s part here in that they wanted to try and help prevent the dime-a-dozen malicious attachment attacks that we’ve all heard about? Don’t get me wrong, I’m no stranger to Microsoft’s strategies— opt-out telemetry, Cortana, bing search in the system tray, etc. It’s not all fueled by just this one particular propriety that I brought up, I know it’s also got a lot to do with their way of pushing their products onto their users with annoying opt-out (at best) features that everyone might not want, that serve to push whatever it is they’re trying to sell to their users.

Point is, at least this specific gripe, for what it’s worth I can see some valid justification for. And if this is new behavior that they intend to stick with, I wouldn’t be surprised if they did improve it over time (although I also wouldn’t be surprised if it stayed as much of an annoyance as you described— bing search in windows remains an unchecked crime against humanity to this very day!)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: