| [05:31:29] | <farmBOT> | @farmOS@fosstodon.org => The #farmOS monthly community call is today at 2pm Eastern. All are welcome! https://farmos.org/community/monthly-call/ => https://fosstodon.org/@farmOS/112246152872359746 |
| [09:12:45] | * jgaehring[m] has joined #farmos |
| [09:12:45] | <jgaehring[m]> | I have been thinking about the [movement logic](https://farmos.org/model/logic/location/) recently, and discussed it a bit yesterday w/ paul121 and Octavio Martín Duarte , and I'm curious to understand better the decision to make 1.x Area taxonomy terms into types of Assets in 2.x, rather than their own Area or Location entity. mstenta, would you say the... (full message at |
| [09:12:46] | <jgaehring[m]> | <https://matrix.org/_matrix/media/v3/download/matrix.org/BTcuJDtKtXkEdAJE...) |
| [09:13:06] | <jgaehring[m]> | (maybe this would be better as a forum post, now that I look at it) |
| [09:14:41] | * symbioquine[m] has joined #farmos |
| [09:14:42] | <symbioquine[m]> | Maybe you can share the gist of the discussion yesterday too? |
| [09:14:45] | * mstenta[m] has joined #farmos |
| [09:14:46] | <mstenta[m]> | jgaehring: yea those are probably the right issues |
| [09:15:03] | <jgaehring[m]> | awesome, thanks! |
| [09:15:30] | <jgaehring[m]> | symbioquine[m]: yea, I'll be there, happy to discuss the background behind this interest |
| [09:15:52] | <mstenta[m]> | if I had to summarize in one sentence it would be: we found in practice that "locations" are almost always treated the same as "assets" - and we were replicating a lot of code to make them work that way for "areas" |
| [09:16:16] | <jgaehring[m]> | ah |
| [09:16:42] | <mstenta[m]> | certainly added some complexity to the data model in some ways, but simplified in a lot more ways... so there were tradeoffs for sure |
| [09:17:12] | <symbioquine[m]> | Off the top of my head, the decision feels very obvious in retrospect - given the use-cases it opens up: locations of implements on tractors (both movable assets), animals in portable locations like chicken tractors, etc |
| [09:18:02] | <symbioquine[m]> | Or in my case, inventory boxes of seed packets |
| [09:18:46] | <jgaehring[m]> | symbioquine[m]: that's a good user scenario to consider |
| [09:19:16] | <symbioquine[m]> | The inventory box locations are themselves tracked and have all the same needs as assets - logs, groupings, flags, etc |
| [09:20:14] | <mstenta[m]> | > certainly added some complexity to the data model in some ways, but simplified in a lot more ways... so there were tradeoffs for sure |
| [09:20:14] | <mstenta[m]> | I forget where I heard this quote recently (maybe someone said it on a dev call?), but it's stuck with me: "there are no solutions - only tradeoffs" :-) |
| [09:21:12] | <symbioquine[m]> | jgaehring[m]: It might be an uncommon enough scenario that it doesn't make sense to design for it explicitly, but I love how moving to farmOS >2 meant our data/processes just fit way more cleanly into the farmOS data model. |
| [09:22:19] | <mstenta[m]> | another good way to think about it: land assets can also be described as "soil" assets... |
| [09:22:35] | <mstenta[m]> | you are managing the soil as an asset just as much (or more) than the plants that go into it |
| [09:23:39] | <jgaehring[m]> | so my interest in this basically boils down to the question: How can this [location logic](https://farmos.org/model/logic/location/#logic) be represented in serialized form, so that it could be replicated on another device, shared over the wire, and versioned in the event of future changes to the algorithm? |
| [09:23:40] | <mstenta[m]> | also worth noting... the distinction "is_location" and "is_fixed" is important |
| [09:23:51] | <mstenta[m]> | with regards to movement, is_location has no effect |
| [09:24:03] | <mstenta[m]> | it's really just about whether or not an asset is considered "fixed" |
| [09:24:57] | <mstenta[m]> | jgaehring: gotcha - makes sense! that's why i wanted to document the "logic" in the model too... it's necessary to understand how the granular "atomic" data is used to construct "current state" |
| [09:25:08] | <mstenta[m]> | (where "current" could be in the past/future too!) |
| [09:25:27] | <mstenta[m]> | "where was this animal last year this time?" |
| [09:25:36] | <mstenta[m]> | is not static |
| [09:25:41] | <symbioquine[m]> | mstenta[m]: (...to the backend - the UI clearly uses the `is_location` attribute to determine what locations are available destinations for moving stuff.) |
| [09:25:45] | <mstenta[m]> | * location is not |
| [09:26:10] | <mstenta[m]> | yes. IIRC is_location is mostly used for UX |
| [09:26:34] | <jgaehring[m]> | jgaehring[m]: and to me there are two ways to approach that... |
| [09:26:35] | <jgaehring[m]> | 1. Serialize the logic, in the form of some kind of RPC or query format or even raw code, or |
| [09:26:35] | <jgaehring[m]> | 2. Make the concept of "movements" into an independent data structure (call that endity, object, or what have you), akin to quantities, so they can be referenced separately from both the asset it refers to and the log that records when and how the action took place |
| [09:27:10] | <mstenta[m]> | ha! movements actually used to be a separate object, similar to quantities, in v1 :-) |
| [09:27:42] | <mstenta[m]> | (but that fact was largely hidden...) |
| [09:27:47] | <jgaehring[m]> | and to jive with what you were saying, mstenta, I don't think either of those are the "right answer", they just come with trade-offs |
| [09:28:01] | <jgaehring[m]> | mstenta[m]: ohhh, did I know that? makes sense, in any event |
| [09:28:11] | <mstenta[m]> | (it was mainly done to make it easier to share fields across log types... but we simplified things in v2 |
| [09:28:56] | <mstenta[m]> | I think you have to have logic to compute location |
| [09:29:08] | <mstenta[m]> | It's sort of unavoidable IMO |
| [09:29:23] | <jgaehring[m]> | <mstenta[m]> "also worth noting... the..." <- yes, I agree, this has been central to my thinking about it as well |
| [09:29:25] | <mstenta[m]> | (gotta jump to a call, back later...) |
| [09:30:37] | <jgaehring[m]> | mstenta[m]: curious the meaning of the second "have" in that statement, hahaha, but "to be continued..." |
| [09:31:31] | <symbioquine[m]> | I interpret it to mean "include an implementation of" |
| [09:31:43] | <jgaehring[m]> | s/endity/entity/ |
| [09:32:21] | <jgaehring[m]> | symbioquine[m]: as in it can't be serialized? |
| [09:32:49] | <symbioquine[m]> | It's clearly possible to express the logic abstractly enough to send it over the wire, but whether it is worth it is trickier to say... |
| [09:33:00] | <jgaehring[m]> | where "implementation" is a "program that runs"? |
| [09:33:23] | <jgaehring[m]> | symbioquine[m]: I guess, assume for argument's sake it's worth it |
| [09:34:00] | <symbioquine[m]> | Since apps like Field Kit or Asset Link will likely have very different internal strategies for handling caching, offline state changes, etc |
| [09:35:17] | <symbioquine[m]> | I mean I'm not totally opposed, but it feels like we're signing up for a much harder problem than just keeping that logic implemented in a few places. |
| [09:36:40] | <jgaehring[m]> | and in some sense, it's not too tricky if you just send code over the wire, you can parse it as an abstract syntax tree and version it and the like, wouldn't even be a very large payload for that kind of logic, but my main concern is that then you've got code that you must evaluate after it's been transported somehow, which is first and foremost a security issue, but also has the potential for more headaches down the road |
| [09:38:12] | <jgaehring[m]> | symbioquine[m]: yea, I don't see any changes, regardless which approach I took, as being integrated into farmOS necessarily, more so that other programs could interact with farmOS more reliably |
| [09:39:21] | <jgaehring[m]> | so again, assume for the moment, "it's worth it," at least for those other programs, and for farmOS assuming we want it to be able to interact with them |
| [09:43:08] | <symbioquine[m]> | <jgaehring[m]> "and in some sense, it's not..." <- I'm not even worried about how to send the code or the security challenges... I'm worried about what abstraction would be needed so the code could generically say "if the asset is not fixed find the latest movement log and use the geometry from that log or the referenced location" |
| [09:44:13] | <symbioquine[m]> | For instance, in Asset Link that would need to be translated into an Orbit.js expression that is aware of the completeness of the caching of the relevant logs. |
| [09:44:46] | <symbioquine[m]> | A desktop application might need to translate it into some SQL query against a SQLite cache. |
| [09:45:02] | <symbioquine[m]> | > <@jgaehring:matrix.org> and in some sense, it's not too tricky if you just send code over the wire, you can parse it as an abstract syntax tree and version it and the like, wouldn't even be a very large payload for that kind of logic, but my main concern is that then you've got code that you must evaluate after it's been transported somehow, which is first and foremost a security issue, but also has the potential for more headaches |
| [09:45:02] | <symbioquine[m]> | down the road |
| [09:45:02] | <symbioquine[m]> | * I'm not even worried about how to send the code or the security challenges... I'm worried about what abstraction would be needed so the code could generically say "if the asset is not fixed find the latest movement log and use the geometry from that log or the referenced location" |
| [09:45:40] | <jgaehring[m]> | yea, the logic is stateful, the way I see it, and that's the core part of the "headaches down the road" I allude to, b/c it gets tricky to guarantee your db doesn't permit an invalid state that still complies with the logic as specified |
| [09:45:53] | <symbioquine[m]> | The abstraction layer that would need to be consistent in both of those applications (such that the can run whatever code farmOS would send) would be bigger than the logic itself. |
| [09:46:28] | <symbioquine[m]> | s/the/they/ |
| [09:46:48] | <symbioquine[m]> | * IMHO, the abstraction layer that would need to be consistent in both of those applications (such that they can run whatever code farmOS would send) would be bigger than the logic itself. |
| [09:47:59] | <symbioquine[m]> | At some level this turns into it's own distributable VM with a dedicated instruction set for manipulating the farmOS data model 🤓 |
| [09:49:28] | <symbioquine[m]> | That might be an interesting problem to solve, but it's pretty far removed from the areas of investment that I think are most urgently needed. |
| [09:50:15] | <jgaehring[m]> | if you were sending code, then yea, you would need an interpreter, but in some cases (as in JS) that's just this amount of code:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/aLCuDfQseWudTBiI...) |
| [09:50:23] | <jgaehring[m]> | is that the best way to do it? probably not |
| [09:51:44] | <jgaehring[m]> | but there are other alternatives for code generation, sanitizing, evaluation, etc. all of which are pretty standard and would mostly just need to be configured |
| [09:52:48] | <jgaehring[m]> | the bigger problem, imo, is the statefulness of the logic, which is in effect the state of your database |
| [09:53:11] | <symbioquine[m]> | jgaehring[m]: Yeah, that's what I said above |
| [09:53:22] | <jgaehring[m]> | which is why I am currently favoring option #1 above, to make the logic stateless, or not logic at all, so you can just represent a movement as values in a data structure |
| [09:54:12] | <jgaehring[m]> | to me, that could be as simple as a sequence of geometries |
| [09:54:13] | <symbioquine[m]> | <jgaehring[m]> "and to me there are two ways..." <- > <@jgaehring:matrix.org> and to me there are two ways to approach that...... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/LGTCBrLJPeBtGVCh...) |
| [09:54:23] | <jgaehring[m]> | yes |
| [09:54:34] | <jgaehring[m]> | oh, sorry, meant # 2 |
| [09:54:36] | <jgaehring[m]> | oops! |
| [09:55:19] | <jgaehring[m]> | * which is why I am currently favoring option ~~#1 above~~ #2 above, to make the logic stateless, or not logic at all, so you can just represent a movement as values in a data structure |
| [09:55:26] | <symbioquine[m]> | I'm not seeing how making "movements" a separate data structure solves the problem |
| [09:55:30] | <jgaehring[m]> | > 2. Make the concept of "movements" into an independent data structure (call that entity, object, or what have you), akin to quantities, so they can be referenced separately from both the asset it refers to and the log that records when and how the action took place |
| [09:56:37] | <jgaehring[m]> | the major trade-off there is that you're now introducing a breaking change to the data model |
| [09:56:42] | <symbioquine[m]> | quantities still have the same problem |
| [09:57:06] | <symbioquine[m]> | * quantities (for inventory) still have |
| [09:57:53] | <symbioquine[m]> | The sum of the quantities over time still needs to be interpreted client-side to tell what the current inventory is. |
| [09:58:31] | <symbioquine[m]> | jgaehring[m]: Maybe we can ignore that problem for now and just talk about why we'd want the resulting data model? |
| [10:01:16] | <jgaehring[m]> | I gotta run for now, but sure |
| [10:01:42] | <symbioquine[m]> | jgaehring[m]: Maybe continue in that forum topic? |
| [10:03:38] | <jgaehring[m]> | I'll have to post something later, out of time for now |
| [10:07:35] | * paul121[m] has joined #farmos |
| [10:07:36] | <paul121[m]> | Just thinking... this would be more interesting/pertinent if the "logic" was "configurable" 🤔 |
| [10:07:56] | <paul121[m]> | eg: if you could choose from a few variations of movement or inventory logic. it would be really important to communicate that |
| [10:11:16] | <symbioquine[m]> | Maybe interpolated tractor locations as a function of time 🧐😅 |
| [10:13:44] | <paul121[m]> | yeaa same with inventory haha |
| [10:16:56] | <symbioquine[m]> | You could model a water resovior and have logs capturing changes in outflow/inflow rate 🤓 |
| [11:20:06] | <mstenta[m]> | I'll throw another wrench: |
| [11:21:28] | <mstenta[m]> | If the Group module is enabled it adds some logic so that assets that are members of a group have the same location as the group 🫣😅 |
| [11:24:50] | <mstenta[m]> | I think our best bet is to document how the logic works in farmOS core, and leave it to other applications to replicate that if/when necessary. Not every application that uses the data needs location, or inventory, or group membership. But if they do, then they should replicate the same logic. |
| [11:31:42] | <jgaehring[m]> | <mstenta[m]> "I think our best bet is to..." <- yea, I like that idea, I am thinking about the ability to serialize and share that logic as being a bonus that the secondary program provides, not that farmOS has to provide, but that way it can maintain interoperability with farmOS while also providing a simplified interface for other programs/services to connect to, so like either a subset or superset of the farmOS data model is what I'm |
| [11:31:42] | <jgaehring[m]> | thinking, and an intermediary if other programs want to use it that way |
| [11:35:21] | <mstenta[m]> | Yea interesting! Trying to wrap my head around it :-) |
| [11:36:13] | <mstenta[m]> | For what it's worth, internally farmOS has a "location service" which encapsulates the logic, and provides a couple of methods that take standard arguments. Maybe it would be useful to review those. |
| [11:36:34] | <symbioquine[m]> | The farmOS API also already includes the computed result of the logic... |
| [11:37:08] | <mstenta[m]> | For example, getLocation() takes an asset and a timestamp as arguments |
| [11:37:13] | <symbioquine[m]> | So the only case where external applications need to do the computation themselves is when they want to see the effect of modifications to the data without first writing them into farmOS. |
| [11:37:30] | <jgaehring[m]> | I want to schedule a time to bring concrete use cases to the table and try out different ways of structuring data for them (JSON Schema, SHACL, or this format CUE I brought up on the forum yesterday) |
| [11:37:32] | <mstenta[m]> | The timestamp defaults to the current time, but can also be used to ask "where was this asset in the past" or "where will it be in the future" |
| [11:37:59] | <mstenta[m]> | Here is the AssetLocationInterface which declares the available methods and their parameters: https://github.com/farmOS/farmOS/blob/3.x/modules/core/location/src/Asse... |
| [11:38:03] | <jgaehring[m]> | mstenta[m]: oh yea! I'd really like to look at those |
| [11:38:34] | <symbioquine[m]> | mstenta[m]: Those these aren't exposed for arbitrary requests via the API at the moment. |
| [11:38:46] | <mstenta[m]> | (other methods include hasLocation(), hasGeometry(), getGeometry(), and getMovementLog()) |
| [11:39:50] | <jgaehring[m]> | at the end of the day, I take the Little Lisper's approach that code is data and data is code, you can always (usually?) represent one with the other... eg, a POST request is just a function, they data fields are parameters, the response the return value |
| [11:40:31] | <symbioquine[m]> | can =/= should |
| [11:41:15] | <symbioquine[m]> | * can ≠ should |
| [11:41:52] | <symbioquine[m]> | Not trying to be confrontational exactly, just pointing out its a big can of worms with a relatively small payoff |
| [11:43:41] | <symbioquine[m]> | Good to formalize/document what the logic is, less clearly good to have farmOS actually vend the logic to clients directly |
| [11:45:05] | <symbioquine[m]> | Unless, as Paul pointed out, we have clear requirements for the logic to be extended in ways that are too varied/exotic/conflicting to be baked into farmOS itself |
| [11:45:30] | <mstenta[m]> | I do see some value... especially considering how modules can override it (like Group)... that isn't currently documented anywhere. But yea it does seem complicated. |
| [11:45:59] | <mstenta[m]> | And ultimately easiest solution is to just document it :-) |
| [11:46:00] | <symbioquine[m]> | and I'd still argue that there are a lot of lower-hanging-fruit in terms of farmOS key features/UX |
| [13:44:27] | <mstenta[m]> | The farmOS monthly call starts in about 15 minutes. All are welcome! https://farmos.org/community/monthly-call/ |
| [13:46:39] | <mstenta[m]> | Agenda - open for ideas! https://farmos.discourse.group/t/farmos-monthly-call-10-april-2024/1972 |
| [13:49:17] | * farmBOT has joined #farmos |
| [14:55:07] | * dazinism[m] has joined #farmos |
| [14:55:18] | * Adam[m] has joined #farmos |
| [14:55:28] | * adinfinitum[m]1 has joined #farmos |
| [14:55:38] | * agrooe[m] has joined #farmos |
| [14:55:48] | * aislinnpearson[m] has joined #farmos |
| [14:55:58] | * AlainaLawrence[m] has joined #farmos |
| [14:56:08] | * almavizca[m] has joined #farmos |
| [14:56:18] | * alphonse86[m] has joined #farmos |
| [14:56:28] | * AllanMacGregor[m] has joined #farmos |
| [14:56:38] | * amber_s[m] has joined #farmos |
| [14:56:48] | * and712[m] has joined #farmos |
| [14:56:58] | * Anonymous[m]1 has joined #farmos |
| [14:57:08] | * ant109[m] has joined #farmos |
| [14:57:18] | * antoine[m] has joined #farmos |
| [14:57:28] | * calbasi[m]1 has joined #farmos |
| [14:57:38] | * BjrnBrala[m] has joined #farmos |
| [14:57:48] | * CarlosAlberto[m] has joined #farmos |
| [14:57:58] | * blm5303[m] has joined #farmos |
| [14:58:08] | * botlfarm[m] has joined #farmos |
| [14:58:17] | * GrantBraught[m] has joined #farmos |
| [14:58:28] | * buddysbestfarm[m] has joined #farmos |
| [14:58:39] | * BuzzKC[m] has joined #farmos |
| [14:58:48] | * canadrian[m] has joined #farmos |
| [14:58:58] | * conservationmaven[m] has joined #farmos |
| [14:58:59] | <symbioquine[m]> | ACTION uploaded an image: (137KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/uwrUyJIDLMojJQHt... > |
| [14:59:08] | * courtneylking[m] has joined #farmos |
| [14:59:17] | * ChristophWolfes[m] has joined #farmos |
| [14:59:23] | <symbioquine[m]> | symbioquine[m]: Participants |
| [14:59:28] | * davd[m] has joined #farmos |
| [14:59:38] | * DavidFrancisco[m] has joined #farmos |
| [14:59:48] | * donblair[m] has joined #farmos |
| [14:59:59] | * OmkarEkbote[m] has joined #farmos |
| [15:00:08] | * dzfarmer[m] has joined #farmos |
| [15:00:18] | * eddieironsmith[m] has joined #farmos |
| [15:00:28] | * EvanKelley[m] has joined #farmos |
| [15:00:38] | * elpronto[m] has joined #farmos |
| [15:00:48] | * SpencerOnazi[m] has joined #farmos |
| [15:00:57] | * EricLarese[m] has joined #farmos |
| [15:01:08] | * SerendibIndustries[m] has joined #farmos |
| [15:01:17] | * evered[m] has joined #farmos |
| [15:01:28] | * f2tmg[m] has joined #farmos |
| [15:01:38] | * FarmerEd[m] has joined #farmos |
| [15:01:47] | * farmtech[m] has joined #farmos |
| [15:01:58] | * FeiWang[m] has joined #farmos |
| [15:02:08] | * NilsNullson[m] has joined #farmos |
| [15:02:18] | * MattFletcher[m] has joined #farmos |
| [15:02:29] | * fosten[m] has joined #farmos |
| [15:02:38] | * frederike[m] has joined #farmos |
| [15:02:48] | * kosnick[m] has joined #farmos |
| [15:02:57] | * FreshiesFarmsLLC[m] has joined #farmos |
| [15:03:08] | * friedrich[m] has joined #farmos |
| [15:03:18] | * gbathree[m] has joined #farmos |
| [15:03:28] | * GediminasVaitkus[m] has joined #farmos |
| [15:03:38] | * GennaFudin[m] has joined #farmos |
| [15:03:48] | * gfudin[m] has joined #farmos |
| [15:03:58] | * ggcc18[m] has joined #farmos |
| [15:04:08] | * GudjonEinarMagnusson[m] has joined #farmos |
| [15:04:18] | * goldi[m] has joined #farmos |
| [15:04:28] | * gretel[m] has joined #farmos |
| [15:04:38] | * guangchunluo[m] has joined #farmos |
| [15:04:48] | * guillermo-farmos[m] has joined #farmos |
| [15:04:57] | * gunter[m] has joined #farmos |
| [15:05:07] | * GerardoLisboa[m] has joined #farmos |
| [15:05:18] | * harry[m] has joined #farmos |
| [15:05:28] | * hra38192639[m] has joined #farmos |
| [15:05:38] | * ian_vai[m] has joined #farmos |
| [15:05:44] | <mstenta[m]> | Thanks! |
| [15:05:47] | * imlostlmao[m] has joined #farmos |
| [15:05:58] | * ionitatelecom[m] has joined #farmos |
| [15:06:08] | * Ian[m]1 has joined #farmos |
| [15:06:18] | * iuresearcherpw[m] has joined #farmos |
| [15:06:28] | * IyarkaiTechLab[m] has joined #farmos |
| [15:06:48] | * JasonJoe[m] has joined #farmos |
| [15:06:58] | * JustinLewis[m] has joined #farmos |
| [15:07:05] | <mstenta[m]> | I wonder if we should just merge https://github.com/farmOS/farmOS/pull/825 for 3.2.0? 😄 |
| [15:07:07] | * Jo[m] has joined #farmos |
| [15:07:18] | * jolau[m] has joined #farmos |
| [15:07:28] | * jrballesteros05[m] has joined #farmos |
| [15:07:38] | * sgoodall[m] has joined #farmos |
| [15:07:48] | * jsoons[m] has joined #farmos |
| [15:07:58] | * JustGav[m] has joined #farmos |
| [15:08:08] | * justgav[m]1 has joined #farmos |
| [15:08:18] | * JustinCampbell[m] has joined #farmos |
| [15:08:27] | * justinestrada[m] has joined #farmos |
| [15:08:38] | * kaizerking[m] has joined #farmos |
| [15:08:48] | * KarsonWynne[m] has joined #farmos |
| [15:08:58] | * kawaiipunkshethey[m] has joined #farmos |
| [15:09:08] | * keylum88[m] has joined #farmos |
| [15:09:18] | * klrmn[m] has joined #farmos |
| [15:09:28] | * RamakrishnaReddy[m] has joined #farmos |
| [15:09:48] | * kunigunde[m] has joined #farmos |
| [15:09:58] | * lauriewayne[m] has joined #farmos |
| [15:10:08] | * leku[m] has joined #farmos |
| [15:10:18] | * leogaggl[m] has joined #farmos |
| [15:10:28] | * lordeddi[m] has joined #farmos |
| [15:10:38] | * ludwa6[m] has joined #farmos |
| [15:10:48] | * marcelo[m] has joined #farmos |
| [15:10:58] | * MarcosCarballal[m] has joined #farmos |
| [15:11:08] | * margeo[m] has joined #farmos |
| [15:11:18] | * matrixtrix[m] has joined #farmos |
| [15:11:28] | * Maty[m] has joined #farmos |
| [15:11:38] | * MaximeLeduc[m] has joined #farmos |
| [15:11:48] | * m035[m] has joined #farmos |
| [15:11:58] | * Mims[m] has joined #farmos |
| [15:12:08] | * mindcls[m] has joined #farmos |
| [15:12:18] | * Mo[m]1 has joined #farmos |
| [15:12:28] | * monkeyflowerfarm[m] has joined #farmos |
| [15:12:38] | * morgs_john[m] has joined #farmos |
| [15:12:48] | * morgsbrew[m] has joined #farmos |
| [15:12:58] | * Mos[m] has joined #farmos |
| [15:13:08] | * mseverething[m] has joined #farmos |
| [15:13:28] | * munjoma[m] has joined #farmos |
| [15:13:38] | * nickhudson[m] has joined #farmos |
| [15:13:48] | * Noaht[m] has joined #farmos |
| [15:13:58] | * nzsnowman[m] has joined #farmos |
| [15:14:08] | * OctavioMartnDuarte[m] has joined #farmos |
| [15:14:18] | * olaf[m] has joined #farmos |
| [15:14:28] | * oliverp44[m] has joined #farmos |
| [15:14:38] | * oswald[m] has joined #farmos |
| [15:14:48] | * PaulC[m] has joined #farmos |
| [15:15:08] | * pcambra[m] has joined #farmos |
| [15:15:18] | * peko[m] has joined #farmos |
| [15:15:28] | * perfectinfoseeker[m] has joined #farmos |
| [15:15:38] | * GuilhermePerotta[m] has joined #farmos |
| [15:15:48] | * petednz[m] has joined #farmos |
| [15:15:58] | * phantomse[m] has joined #farmos |
| [15:16:09] | * AnthonyRitter[m] has joined #farmos |
| [15:16:18] | * piegeux[m] has joined #farmos |
| [15:16:28] | * EricMeadows[m] has joined #farmos |
| [15:16:38] | * postmanpat[m] has joined #farmos |
| [15:16:48] | * PradiptaSaha[m] has joined #farmos |
| [15:16:58] | * qoyyuum[m] has joined #farmos |
| [15:17:07] | * valida-69[m] has joined #farmos |
| [15:17:18] | * r3c4ll[m] has joined #farmos |
| [15:17:28] | * RafatKhashan[m] has joined #farmos |
| [15:17:38] | * ratapenail[m] has joined #farmos |
| [15:17:48] | * raul[m] has joined #farmos |
| [15:17:58] | * riotmiked[m] has joined #farmos |
| [15:18:08] | * RogerioMbuli[m] has joined #farmos |
| [15:18:17] | * royills[m] has joined #farmos |
| [15:18:28] | * runfastthinkslow[m] has joined #farmos |
| [15:18:38] | * samrose[m] has joined #farmos |
| [15:18:47] | * sandg100[m] has joined #farmos |
| [15:18:58] | * AnasHaddad[m] has joined #farmos |
| [15:19:07] | * scrdcow[m] has joined #farmos |
| [15:19:18] | * shane_aldrich[m] has joined #farmos |
| [15:19:28] | * shmida[m] has joined #farmos |
| [15:19:38] | * shplorf[m] has joined #farmos |
| [15:19:48] | * sj-techjorblad[m] has joined #farmos |
| [15:19:58] | * skalakm[m] has joined #farmos |
| [15:20:08] | * skipper_is[m] has joined #farmos |
| [15:20:18] | * BrandonSmith[m] has joined #farmos |
| [15:20:28] | * spacespy[m] has joined #farmos |
| [15:20:37] | * spitz234[m] has joined #farmos |
| [15:20:48] | * Spixmaster[m] has joined #farmos |
| [15:20:58] | * steinfarm[m] has joined #farmos |
| [15:21:07] | * steve456[m]1 has joined #farmos |
| [15:21:17] | <mstenta[m]> | botlfarm: ^ |
| [15:21:18] | * JanSonntag[m] has joined #farmos |
| [15:21:38] | * anderclick[m] has joined #farmos |
| [15:21:48] | * t4cradle[m] has joined #farmos |
| [15:21:58] | * HiraHaleem[m] has joined #farmos |
| [15:22:08] | * tamtran94[m] has joined #farmos |
| [15:22:18] | * tamtran[m] has joined #farmos |
| [15:22:28] | * testuser769[m] has joined #farmos |
| [15:22:38] | * thattechguy99[m] has joined #farmos |
| [15:22:48] | * thattechguy[m] has joined #farmos |
| [15:22:58] | * TheSlurpee[m] has joined #farmos |
| [15:23:08] | * Thimm[m] has joined #farmos |
| [15:23:18] | * todrobbinshehim[m] has joined #farmos |
| [15:23:28] | * toino[m] has joined #farmos |
| [15:23:38] | * tool172[m] has joined #farmos |
| [15:23:48] | * UgeshB[m] has joined #farmos |
| [15:23:58] | * Ujeeee[m] has joined #farmos |
| [15:24:08] | * UzelJames[m] has joined #farmos |
| [15:24:17] | * MatrixTravelerbot[m] has joined #farmos |
| [15:24:28] | * wildhavenfarm[m] has joined #farmos |
| [15:24:38] | * wombat83[m] has joined #farmos |
| [15:24:48] | * wotnak[m] has joined #farmos |
| [15:24:58] | * DavidWilson[m] has joined #farmos |
| [15:25:08] | * yaaitha[m] has joined #farmos |
| [15:25:17] | * yahtu[m] has joined #farmos |
| [15:25:28] | * YashGoel[m] has joined #farmos |
| [15:25:38] | * zackmuma[m] has joined #farmos |
| [15:25:48] | * ZaneBelkhayat[m] has joined #farmos |
| [15:25:58] | * zedrickr11[m] has joined #farmos |
| [15:36:02] | <mstenta[m]> | And @room ^ |
| [15:36:06] | <mstenta[m]> | 😄 |
