Endle/fireSeqSearch

Browser Search and Autosuggest support

brandonkal opened this issue · 8 comments

brandonkal commented

Provide the following API endpoints:
http://localhost/?q=%s
where that page is a result is a redirect to the first matching logseq page (logseq app link)

Provide an API endpoint on the server in the form of
http://localhost/ac/?q=%s

Where %s is the search term. For example the endpoint would return the following list for "apple"

["apple",["apple","apple music","apple store","apple tv","apple stock","apple watch","applebee's","apple tv +"]]

Where "apple" is the search query and the other list items are results (as suggestions)

This would allow searching Logseq directly from the browser's address bar. i.e. LTab apple

Endle commented

Hi Brandon,

I'm sorry that I didn't get the point. Currently, the server API is

http://127.0.0.1:3030/query/%s (or http://localhost:3030/query/%s )

Can you explain a bit more that what API you're expecting?

brandonkal commented

SearchSuggestions

Providing such an API allows me to type "<engine-prefix> what I am looking for" and the results are listed as suggestions here in the browser. In this case I am using "d" for a DuckDuckGo search. But it would be nice to be able to prefix a search with "l" for Logseq and be able to click or enter on a suggestion to be taken directly to the matching page in Logseq.

Endle commented

Hi Brandon,

To make our discussion clear, I just created a server doc https://github.com/Endle/fireSeqSearch/blob/master/docs/server.md

Provide the following API endpoints: http://localhost/?q=%s where that page is a result is a redirect to the first matching logseq page (logseq app link)

Do you mean that is something like Google's I'm feeling lucky? Instead of giving a list, it would re-direct you to logseq immediately.

It's not difficult for me to add it at server side. However, I'm a bit uncertain with this idea. My current experience is that false positive rate is quite high[1], and it's very common that the top hit is not what I want. As you might use another way to use logseq, the top hit quality might be better or worse than mine.

If you'd like to have a try, I'll add an endpoint. Can I use the address

http://127.0.0.1:3030/lucky_query/%s

[1]: I'm not to blame tantivy. I think I should adjust the configuration a bit.

Provide an API endpoint on the server in the form of http://localhost/ac/?q=%s

Providing such an API allows me to type " what I am looking for" and the results are listed as suggestions here in the browser.

Now I got your point. It is very interesting, and I've been attracted to it. I'll try to implement it, but I don't know how yet. Please don't take it as a promise.

I still have questions: who (which software) would read this endpoint? Browser? macOS? Can I use an endpoint like

http://127.0.0.1:3030/query_term_suggest/%s

brandonkal commented

The idea here is to use the browser’s UI as an alternative search interface. So the “Suggestions” list are actual results (ie Logseq page names) and then clicking that suggestion/result takes you to the Logseq page. So it would have to behave in a way that redirects to the app.

Maybe it is not the right fit for this software but it seems cool that it is technically possible.

Endle commented

Hi,

Maybe it is not the right fit for this software but it seems cool that it is technically possible.

Nope. I think this feature is very interesting. As I mentioned, I'll try to implement it, but I don't know how yet. Please don't take it as a promise.

The idea here is to use the browser’s UI as an alternative search interface.

Here is my blocker. I have no knowledge about what the browser expects me to do.

Could you make a PR to https://github.com/Endle/fireSeqSearch/blob/master/docs/server.md ?
If the endpoint is formally defined, I could have a start on this job

brandonkal commented

Okay, I submitted the PR. It took some time to figure out where this format is defined as Amazon has repurposed the opensearch.org domain but the format has been stable to the spec for the last decade.

Vivaldi appears to only use the required fields in the spec which is why the lucky endpoint is also required.
Firefox supports this as well but it appears it requires an extension to add search engines to that browser (as far as I can tell, I haven't used Firefox for some time).

Here are some other references I came across
https://www.mediawiki.org/wiki/API:Opensearch
https://neeva.com/suggest?q=apple&src=opensearch
https://duckduckgo.com/ac/?q=apple&type=list
https://vivaldi-wiki.readthedocs.io/Settings/add-search-suggestions-to-search-engines/

Endle commented

#42 (comment)

Thank you so much! The reference you shared and your PR is super helpful for me.

I'll be working on it right now, although I couldn't provide timeline for it

Endle commented

Hi @brandonkal

Merry Christmas and Happy Holidays.

I'm afraid that I misunderstood your request at the very beginning. Please let me confirm a question with such an example

Assume in your logseq notebook, you have a few notes with titles
["apple","apple music","apple store"]

Also, the word "apple" appears in such notes
["fruit price", "personal computer", "grocery"]

When you use the endpoint http://127.0.0.1:3030/query/apple, the returned json should be

[
    "apple",
    ["apple","apple music","apple store", "fruit price", "personal computer", "grocery"],
    ["summary ... ", ...],
    [
    "http://localhost:3030/lucky/apple",
    "http://localhost:3030/lucky/apple music",
    "etc..."
    ]
]

Is my interpretation correct?