akdom's comments

A key tool missing in most applications of MCP is better underlying authorization controls. Instead of granting large-scale access to data like this at the MCP level, just-in-time authorization would dramatically reduce the attack surface.

See the point from gregnr on

> Fine-grain permissions at the token level. We want to give folks the ability to choose exactly which Supabase services the LLM will have access to, and at what level (read vs. write)

Even finer grained down to fields, rows, etc. and dynamic rescoping in response to task needs would be incredible here.

Specifically to the point of the comparatively low reliability / high variation of analog systems: an interesting property of neural nets is that they can be robust relative to noise when trained with the same type of noise witnessed under inference.

Whether or not speed/etc. would be better in the digital vs. analog design-space, it's an interesting thing to consider that neural nets can automatically account for the encoding-medium's variability. This perhaps makes neural solutions a good fit for low power analog media which otherwise aren't useful for classical computing.

See https://arxiv.org/abs/2104.13386 for an exploration of physically encoding neural architectures.

+1 to @sillysaurusx's comment. I'd like to add on a recommendation to read The Cold Start Problem by Andrew Chen. It goes into the trials and tribulations of creating a product dependent on network effects.

More than just a problem of no longer having an "artificial" influx of users via HN, you will need to figure out how to build what Chen calls an "Atomic Network" of users who are self-sustaining on the platform. The first step to that end will be figuring out how to attract the "hard side" of the network (i.e. people who find good papers and post them). What keeps them coming back?

I'd highly recommend considering what the smallest network of users would be that could sustain something like Paperlist and what features they might want.

Some questions that might be helpful to get started: * What incentive does a given user have to return to the site? * How would a user be drawn back to the site, e.g. RSS, notifications, etc.? * What incentive does a user have to contribute to Paperlist over submitting to HN, reddit, etc.? * How do you attract a new user the to site? Put another way: how do you increase the "virality" of Paperlist? E.g. why would someone link to Paperlist today instead of Arxiv?

I hope this is helpful.

Alright, I can see the case where someone doesn't habitually close it and stumbles upon a site where it is obscuring. It seems rather mild to me, but I guess I could regard that as a UX failing.

The only solutions that immediately come to mind:

A) Place the "Find on Page" box at the bottom of the window.

Advantages: It would get out of the way for the common practice of placing web UI at the top of the viewing pane. Also the tradition of putting other UI elements at the bottom (namely the download bar comes to mind) means that it wouldn't be too unfamiliar.

Drawbacks: This _would_ put it rather far from it's omnibox UI-sibling and the rest of the prefs UI, breaking some of the association for the UX. It doesn't resolve the problem of UI elements being obscured the bottom of the viewing pane.

Seen also in: I know at least Firefox does this.

B) Have the "Find on Page" UI element displace the page so as to not cover any page UI while "active"

Advantages: Won't cover UI. Potentially more room for search terms.

Drawbacks: Takes up more screen real estate.

Seen also in: I know at least Firefox does this as well.

Alright, so those are potential solutions... what I'm more interested in are the ones I _haven't_ thought of. Does anyone in the HN community have a brilliant solution for how to deal with designing a "Find on Page" UI?

But if you're searching for specific content it seems to fall into two categories:

A) The content _is_ the UI element that's being covered and the search box moves out of the way.

B) The content _is not_ the UI element that's being covered and you are looking to find something else on the page.

I don't leave the "Find on Page" box open when I'm normally using a page. So when searching I'm not really interacting with that UI, and when not searching it isn't being obstructed... so does this really constitute a UX issue?

Yeah... this one threw me for a loop while I was reading the post... then I realized it. In OS X the whole top of the window is a continuous gradient (all the way from the top edge to the bottom of the primary toolbar). So the OP's complaint appears to be that that the Chrome window renders as though it's in Window/Linux instead of Mac OS X even though it has the brushed aluminum look. This also goes for the "Non-native behavior, Native look" point. In OS X you can drag from anywhere on the gradient, while in Chrome it just "looks" like it's doing shiny Cocoa things.