Pull to refresh

Comments 7

Месседжеры для этого вообще не подходят. И UI для этого также - не лучшая идея.

Для этого подходят документы:

  1. Постановка

  2. DOR

  3. Анализ

  4. Техрешение

  5. DOD

  6. Спецификации

  7. Проверки

  8. Отчёт

И да, я иронизирую, но лишь отчасти. Все эти документы символизируют ПРОЦЕСС. Вы можете какую-то часть этого процесса поручить агенту, когда процесс у вас есть. Но если процесса нет - то никакой интерфейс к стае стохастичных попугаев не спасёт от энтропии..

Всегда удивлялся безумцам, которые запускают и пользуются OpenClaw.

И всё это превращается в длинную ленту сообщений.

Проблема в том, что мессенджеры просто не рассчитаны на такой тип данных.

После прочтения вижу, что у вас тоже может быть длинный чат.

Мессенджеры буквально рассчитаны на тип данных «длинная лента сообщений».

выросла мобильная консоль

я хотел написать

появилась идея

появилась идея

Поэтому приложение умеет:

Поэтому появились отдельные экраны

Позже появился ещё один эксперимент

получилась мобильная консоль для сервера

Проект всё ещё активно развивается

Не могу понять, кто написал приложение — идеи и фичи «появились» и «выросли», проект «развивается» и «получился».

Вас зовут Дмитрий? В RuStore всего одна оценка и один отзыв двухнедельной давности. Это совпадение?

Почему опубликовано только в RuStore?

Почему нет исходных кодов?

Большинство мобильных SSH-клиентов по сути выполняют команды как отдельные exec-вызовы. Это неудобно, потому что не сохраняется состояние shell.

Различие shell и exec — это не базовая фича про интерактивность из пункта 6.5 документа RFC 4254?

Вообще ни один клиент не поддерживает подобное: ни ConnectBot, ни JuiceSSH, ни WebSSH?

Это скорее лёгкий operational dashboard, который позволяет быстро понять, что происходит с сервером.

Чем вам не угодил DaRemote?

Не разбираюсь в технических деталях, но уровни стэка выглядят странно. Зачем gateway через WebSocket через SSH-туннель? Зачем host → container → pod?

Поэтому приложение умеет:

  • читать файлы на сервере

  • показывать diff

  • принимать или отклонять изменения

Подано, как тривиальная задача, но что если будет параллельное редактирование?

По сути это попытка сделать локального AI-оператора для сервера.

Локальный ИИ-оператор на смартфоне для управления сервером, где крутится ИИ-агент?

Наконец, зачем доверять одному самописному инструменту с закрытыми исходниками самый глубокий доступ к серверу, где могут лежать неизвестные объёмы чувствительных данных и банально ключи доступа?

И почему теперь тоже пишу короткие абзацы из одного предложения — я заразился?

Спасибо за отзыв!
1) Приложение написал я
2) Отзыв в rustore каюсь, написал сам. Скорее просто хотел посмотреть как это будет выглдять в консоли разработчика, чем кого то обманывать фековым отзывом, да и кто так делает вообще)))
3) Почему только в rustore - в скором времени появится и в других сторах, ожидаю модерацию
4) Про локального ИИ агента на мобилке - это скорее как альтернатива серверному openclaw. Рассматриваю его больше как эксп у которого есть свои минусы и плюсы
5) На счет доверия и opensource, хороший поинт, я в целом подумываю о том, чтобы выложить сорцы, но пока только на уровне идеи. Если кто то еще поддерживает это мнение, ставьте плюсы - выложу сорцы

Плюс поставить не могу по причине недостаточной "кармы", но в целом вам плюс :)

По ощущениям, интерфейс в телеграмме сам по себе ограниченный, мобильное приложение конечно удобнее. Но подумайте насчёт того, чтобы сделать удобный клиент и для компа:)

Насчёт опенсорса - дело хорошее, но тогда вы монетизировать вашу программу будет сложнее, но тут вопрос в том, монетизируется ли это в современных реалиях избытка программ для AI. В целом - я за опенсорс, конечно, это в любом случае это позитивный фон для разработчика:)

А мне понравилась идея. Буду тестить)

Спасибо! В случае возникновении проблем можете отправить репорт прямо в приложении, оперативно рассмотрю и в случае чего подправлю

Супер долго боролся с appstore пропустить приложение.
Дважды отклоняли из за возможности вставить api ключ от модели без оплаты в appstore

The app unlocks or enables additional functionality with mechanisms other than In-App Purchase, which is not appropriate. Specifically, the app uses API keys to unlock or enable paid functionality, but some of these API keys are not available for purchase via In-App Purchase in this or the associated apps by the API provider on the App Store. Next Steps It would be appropriate to remove these features from the app and any other feature that unlocks or enables functionality with mechanisms other than the App Store. You may also consider making this unlocked content available to your users as In-App Purchases.Please note API keys can only be used to unlock content if those API keys can be purchased with In-App Purchase in this or the associated app by the API provider on the App Store.
The app unlocks or enables additional functionality with mechanisms other than In-App Purchase, which is not appropriate. Specifically, the app uses API keys to unlock or enable paid functionality, but some of these API keys are not available for purchase via In-App Purchase in this or the associated apps by the API provider on the App Store. Next Steps It would be appropriate to remove these features from the app and any other feature that unlocks or enables functionality with mechanisms other than the App Store. You may also consider making this unlocked content available to your users as In-App Purchases.Please note API keys can only be used to unlock content if those API keys can be purchased with In-App Purchase in this or the associated app by the API provider on the App Store.

Ответил на это так

Hello,  Thank you for your feedback.  We would like to clarify the purpose of API key usage in our application.  The app is a developer-oriented infrastructure tool (including SSH, file management, Docker, and Kubernetes features). The AI functionality is an optional component designed for automation and interaction with user-owned systems.  The API key is not used to unlock or enable paid functionality within the app. Instead, it is used solely to connect the app to an external service that the user already controls. This may include:   self-hosted or local AI models,  private infrastructure endpoints, * or third-party services where the user already has an account.  In many cases, these services are free, locally hosted, or already provisioned outside of the app. The app does not sell, provide, or broker access to any AI services, and it does not direct users to purchase anything outside the App Store.  Therefore, the API key functions as a configuration mechanism for integrating user-owned infrastructure, rather than a method of unlocking paid content or features.  Could you please advise how we can adjust our implementation to comply with guideline 3.1.1 in this scenario, given that the app only connects to user-provided services and does not sell or provide digital content?  We would appreciate any specific guidance you can provide.
Hello, Thank you for your feedback. We would like to clarify the purpose of API key usage in our application. The app is a developer-oriented infrastructure tool (including SSH, file management, Docker, and Kubernetes features). The AI functionality is an optional component designed for automation and interaction with user-owned systems. The API key is not used to unlock or enable paid functionality within the app. Instead, it is used solely to connect the app to an external service that the user already controls. This may include: self-hosted or local AI models, private infrastructure endpoints, * or third-party services where the user already has an account. In many cases, these services are free, locally hosted, or already provisioned outside of the app. The app does not sell, provide, or broker access to any AI services, and it does not direct users to purchase anything outside the App Store. Therefore, the API key functions as a configuration mechanism for integrating user-owned infrastructure, rather than a method of unlocking paid content or features. Could you please advise how we can adjust our implementation to comply with guideline 3.1.1 in this scenario, given that the app only connects to user-provided services and does not sell or provide digital content? We would appreciate any specific guidance you can provide.

Спустя 4 дня снова получил

Hello, Thank you for your reply. Regarding 3.1.1, the app uses API keys to unlock or enable paid functionality, but some of these API keys are not available for purchase via In-App Purchase in this or the associated apps by the API provider on the App Store. To resolve this issue, it would be appropriate to remove these features from the app and any other feature that unlocks or enables functionality with mechanisms other than the App Store. You may also consider making this unlocked content available to your users as In-App Purchases.
Hello, Thank you for your reply. Regarding 3.1.1, the app uses API keys to unlock or enable paid functionality, but some of these API keys are not available for purchase via In-App Purchase in this or the associated apps by the API provider on the App Store. To resolve this issue, it would be appropriate to remove these features from the app and any other feature that unlocks or enables functionality with mechanisms other than the App Store. You may also consider making this unlocked content available to your users as In-App Purchases.


Это было уже на грани срыва

Hello, Thank you for your response. We believe this may be a misunderstanding of how API keys are used in the app. The app does not unlock or enable any paid functionality. The API key is only used as a configuration parameter to connect to user-owned or external services, similar to entering SSH credentials or server endpoints. No features are gated behind payment, and the app does not provide or sell any digital content or services. Given that the same functionality is available regardless of API key presence, we respectfully believe that guideline 3.1.1 may have been misinterpreted in this case. Could you please clarify which specific functionality is considered “paid content unlocking”? Additionally, we kindly request that this review be escalated to a senior reviewer or the App Review Board for further evaluation. We are committed to complying with all App Store guidelines and would appreciate more specific guidance. Best regards
Hello, Thank you for your response. We believe this may be a misunderstanding of how API keys are used in the app. The app does not unlock or enable any paid functionality. The API key is only used as a configuration parameter to connect to user-owned or external services, similar to entering SSH credentials or server endpoints. No features are gated behind payment, and the app does not provide or sell any digital content or services. Given that the same functionality is available regardless of API key presence, we respectfully believe that guideline 3.1.1 may have been misinterpreted in this case. Could you please clarify which specific functionality is considered “paid content unlocking”? Additionally, we kindly request that this review be escalated to a senior reviewer or the App Review Board for further evaluation. We are committed to complying with all App Store guidelines and would appreciate more specific guidance. Best regards

И спустя 4 дня наконец то получил

Hello, Thank you for providing this information.  We will continue to review your app, and will notify you if there are any further issues. Best regards, App Review
Hello, Thank you for providing this information. We will continue to review your app, and will notify you if there are any further issues. Best regards, App Review

https://apps.apple.com/ru/app/mobcode/id6759875417

Sign up to leave a comment.

Articles