Pre-submission checklist | 提交前检查
Problem Statement | 问题陈述
MemOS can retrieve general web results through its internet retriever factory. It cannot retrieve public X posts through that same typed path.
This matters for memory tasks built around recent public announcements, incident updates, or community discussion. An application can call an X API outside MemOS, but then it must recreate MemOS's source metadata, embeddings, deduplication, result limits, and failure handling.
I propose an opt-in xquik internet retriever. It would use Xquik's published, read-only tweet search endpoint and map each result into TextualMemoryItem.
The implementation would:
- register
xquik in both internet retriever factories;
- authenticate with
X_TWITTER_SCRAPER_API_KEY through the x-api-key header;
- support a configurable base URL, result limit, timeout, and
Latest or Top ordering;
- preserve the tweet URL, ID, author, creation time, language, and engagement fields in memory metadata;
- deduplicate by tweet ID before embedding results;
- reuse the existing
requests dependency, with no new package;
- keep API failures isolated and avoid logging credentials or response bodies;
- add mocked unit tests for conversion, limits, duplicate results, missing optional fields, and HTTP errors;
- add a focused example without making live network calls in tests.
Only the public search route would be in scope. This would not expose posting, liking, following, direct messaging, or other write actions.
Would this backend and configuration shape fit the internet retriever roadmap? I am willing to implement it after maintainers confirm the scope.
Xquik is an independent third-party service. Not affiliated with X Corp. "Twitter" and "X" are trademarks of X Corp.
Willingness to Implement | 实现意愿
Pre-submission checklist | 提交前检查
Problem Statement | 问题陈述
MemOS can retrieve general web results through its internet retriever factory. It cannot retrieve public X posts through that same typed path.
This matters for memory tasks built around recent public announcements, incident updates, or community discussion. An application can call an X API outside MemOS, but then it must recreate MemOS's source metadata, embeddings, deduplication, result limits, and failure handling.
I propose an opt-in
xquikinternet retriever. It would use Xquik's published, read-only tweet search endpoint and map each result intoTextualMemoryItem.The implementation would:
xquikin both internet retriever factories;X_TWITTER_SCRAPER_API_KEYthrough thex-api-keyheader;LatestorTopordering;requestsdependency, with no new package;Only the public search route would be in scope. This would not expose posting, liking, following, direct messaging, or other write actions.
Would this backend and configuration shape fit the internet retriever roadmap? I am willing to implement it after maintainers confirm the scope.
Xquik is an independent third-party service. Not affiliated with X Corp. "Twitter" and "X" are trademarks of X Corp.
Willingness to Implement | 实现意愿